Machine Learning Portfolio Simulating and Optimizing Apparatuses, Methods and Systems

ABSTRACT

The Machine Learning Portfolio Simulating and Optimizing Apparatuses, Methods and Systems (“MLPO”) transforms machine learning simulation request, decision tree ensembles training request, expected returns calculation request, portfolio construction request, predefined scenario construction request, portfolio returns visualization request inputs via MLPO components into machine learning simulation response, decision tree ensembles training response, expected returns calculation response, portfolio construction response, predefined scenario construction response, portfolio returns visualization response outputs. User selection of simulated market scenarios generated using neural networks is obtained. A range of unfiltered simulated market factor values for each market factor is determined. Customized market factors are updated based on a user modification. A range of allowable values for each customized market factor is determined. Simulated market scenarios are filtered based on the determined ranges of allowable values. A range of filtered simulated market factor values for each market factor is determined. Updated market factor interaction-interface mechanisms are generated.

PRIORITY CLAIM

Applicant hereby claims benefit to priority under 35 USC § 119 as anon-provisional conversion of: U.S. provisional patent application Ser.No. 63/055,876, filed Jul. 23, 2020, entitled “Machine LearningPortfolio Simulating and Optimizing Apparatuses, Methods and Systems”,(attorney docket no. Fideli 0663PV).

The entire contents of the aforementioned applications are hereinexpressly incorporated by reference.

This application for letters patent disclosure document describesinventive aspects that include various novel innovations (hereinafter“disclosure”) and contains material that is subject to copyright, maskwork, and/or other intellectual property protection. The respectiveowners of such intellectual property have no objection to the facsimilereproduction of the disclosure by anyone as it appears in publishedPatent Office file/records, but otherwise reserve all rights.

OTHER APPLICATIONS

Applications of interest include: U.S. patent application Ser. No.14/494,443, filed Sep. 23, 2014, entitled “Life Cycle Based PortfolioConstruction Platform Apparatuses, Methods and Systems”, (attorneydocket no. Fidelity-0148US); U.S. patent application Ser. No.14/286,792, filed May 23, 2014, entitled “SEASONAL PORTFOLIOCONSTRUCTION PLATFORM APPARATUSES, METHODS AND SYSTEMS”, (attorneydocket no. Fidelity-0002US2); U.S. patent application Ser. No.14/032,140, filed Sep. 19, 2013, entitled “SECTOR-BASED PORTFOLIOCONSTRUCTION PLATFORM APPARATUSES, METHODS AND SYSTEMS”, (attorneydocket no. FIDE-001/01US270718-2003), U.S. patent application Ser. No.13/370,396, filed Feb. 10, 2012, entitled “MULTI-FACTOR RISK MODELINGPLATFORM”, (attorney docket no. FidelityFR06US).

The entire contents of the aforementioned applications are hereinexpressly incorporated by reference.

FIELD

The present innovations generally address machine learning and databasesystems, and more particularly, include Machine Learning PortfolioSimulating and Optimizing Apparatuses, Methods and Systems.

However, in order to develop a reader's understanding of theinnovations, disclosures have been compiled into a single description toillustrate and clarify how aspects of these innovations operateindependently, interoperate as between individual innovations, and/orcooperate collectively. The application goes on to further describe theinterrelations and synergies as between the various innovations; all ofwhich is to further compliance with 35 U.S.C. § 112.

BACKGROUND

People own all types of assets, some of which are secured instruments tounderlying assets. People have used exchanges to facilitate trading andselling of such assets. Computer information systems, such as NAICO-NET,Trade*Plus and E*Trade allowed owners to trade securities as setselectronically.

BRIEF DESCRIPTION OF THE DRAWINGS

Appendices and/or drawings illustrating various, non-limiting, example,innovative aspects of the Machine Learning Portfolio Simulating andOptimizing Apparatuses, Methods and Systems (hereinafter “MLPO”)disclosure, include:

FIGS. 1A-B show a datagraph illustrating data flow(s) for the MLPO;

FIGS. 2A-B show a logic flow illustrating embodiments of a machinelearning simulated scenario processing (MLSSP) component for the MLPO;

FIG. 3 shows an architecture for the MLPO;

FIG. 4 shows a logic flow illustrating embodiments of a machine learningsimulated scenario processing (MLSSP) component for the MLPO;

FIG. 5 show a logic flow illustrating embodiments of a decision treeensembles training (DTET) component for the MLPO;

FIGS. 6A-D show implementation case(s) for the MLPO;

FIGS. 7A-C show a logic flow illustrating embodiments of an expectedreturns calculation (ERC) component for the MLPO;

FIG. 8 shows a datagraph illustrating data flow(s) for the MLPO;

FIG. 9 shows a logic flow illustrating embodiments of a portfolioconstructing (PC) component for the MLPO;

FIG. 10 shows a screenshot illustrating user interface(s) of the MLPO;

FIG. 11 shows a screenshot illustrating user interface(s) of the MLPO;

FIG. 12 shows a screenshot illustrating user interface(s) of the MLPO;

FIG. 13 shows a datagraph illustrating data flow(s) for the MLPO;

FIGS. 14A-B show a logic flow illustrating embodiments of a predefinedscenario constructing (PSC) component for the MLPO;

FIG. 15 shows a screenshot illustrating user interface(s) of the MLPO;

FIG. 16 shows a screenshot illustrating user interface(s) of the MLPO;

FIG. 17 shows a screenshot illustrating user interface(s) of the MLPO;

FIG. 18 shows a screenshot illustrating user interface(s) of the MLPO;

FIG. 19 shows a screenshot illustrating user interface(s) of the MLPO;

FIG. 20 shows a datagraph illustrating data flow(s) for the MLPO;

FIG. 21 shows a logic flow illustrating embodiments of a scenario basedportfolio returns visualizing (SPRV) component for the MLPO;

FIG. 22 shows a screenshot illustrating user interface(s) of the MLPO;

FIG. 23 shows a screenshot illustrating user interface(s) of the MLPO;

FIG. 24 shows a screenshot illustrating user interface(s) of the MLPO;

FIG. 25 shows a screenshot illustrating user interface(s) of the MLPO;

FIG. 26 shows a datagraph illustrating data flow(s) for the MLPO;

FIG. 27 shows a logic flow illustrating embodiments of a business cyclebased portfolio returns visualizing (BPRV) component for the MLPO;

FIG. 28 shows a screenshot illustrating user interface(s) of the MLPO;

FIG. 29 shows a screenshot illustrating user interface(s) of the MLPO;

FIG. 30 shows a screenshot illustrating user interface(s) of the MLPO;

FIG. 31 shows an architecture for the MLPO;

FIG. 32 shows an architecture for the MLPO;

FIGS. 33A-B show an architecture for the MLPO;

FIG. 34 shows a datagraph illustrating data flow(s) for the MLPO;

FIG. 35 shows a logic flow illustrating embodiments of a portfolioreturns visualizing (PRV) component for the MLPO;

FIG. 36 shows a logic flow illustrating embodiments of an asset returnmetrics calculating (ARMC) component for the MLPO;

FIG. 37 shows an architecture for the MLPO;

FIG. 38 shows an architecture for the MLPO;

FIG. 39 shows an architecture for the MLPO;

FIG. 40 shows an architecture for the MLPO;

FIG. 41 shows a screenshot illustrating user interface(s) of the MLPO;

FIG. 42 shows a screenshot illustrating user interface(s) of the MLPO;

FIG. 43 shows a screenshot illustrating user interface(s) of the MLPO;

FIG. 44 shows a screenshot illustrating user interface(s) of the MLPO;

FIG. 45 shows a screenshot illustrating user interface(s) of the MLPO;

FIG. 46 shows a screenshot illustrating user interface(s) of the MLPO;

FIG. 47 shows a screenshot illustrating user interface(s) of the MLPO;

FIG. 48 shows an architecture for the MLPO;

FIG. 49 shows an architecture for the MLPO (e.g., Mutual Fund/ETF ModelArchitecture);

FIG. 50 shows an architecture for the MLPO (e.g., Mutual Fund/ETF PseudoCode—Parallel Computing);

FIG. 51 shows an architecture for the MLPO (e.g., Mutual Fund/ETFDatabase Tables);

FIG. 52 shows an architecture for the MLPO (e.g., Mutual Fund/ETF PseudoCode—Proprietary Feature Selection);

FIG. 53 shows a screenshot illustrating user interface(s) of the MLPO(e.g., Market Risk Factor Exposure);

FIG. 54 shows a screenshot illustrating user interface(s) of the MLPO(e.g., Simulated Return Distribution Conditional on Market Scenario);

FIG. 55 shows a screenshot illustrating user interface(s) of the MLPO(e.g., Simulated Return Distribution Conditional on Business Cycle);

FIG. 56 shows an architecture for the MLPO (e.g., EQUITY RISK MODELINGWORKFLOW);

FIG. 57 shows an architecture for the MLPO (e.g., PROPRIETARY FEATURESELECTION METHOD);

FIG. 58 shows a screenshot illustrating user interface(s) of the MLPO(e.g., PMRI RISK ANALYSIS SCREENSHOT);

FIG. 59 shows a screenshot illustrating user interface(s) of the MLPO(e.g., MRI RISK ANALYSIS RETURN DRIVER SCREENSHOT);

FIG. 60 shows a screenshot illustrating user interface(s) of the MLPO(e.g., PMRI RISK ANALYSIS BUSINESS CYCLE SCREENSHOT);

FIG. 61 shows a screenshot illustrating user interface(s) of the MLPO(e.g., PMRI RISK ANALYSIS RISING VIX SCENARIO SCREENSHOT);

FIG. 62 shows an architecture for the MLPO (e.g., PARALLEL COMPUTINGPSEUDOCODE);

FIG. 63 shows an architecture for the MLPO (e.g., EQUITY RISK MODELINGFEATURE ENGINEERING WORKFLOW);

FIG. 64 shows an architecture for the MLPO (e.g., EQUITY IDIOSYNCRATICRISK MODELING WORKFLOW);

FIG. 65 shows a screenshot illustrating user interface(s) of the MLPO(e.g., Δ VIX VS HISTORICAL UNPRECEDENTEDNESS);

FIG. 66 shows a screenshot illustrating user interface(s) of the MLPO(e.g., HISTORICAL VS VAE);

FIG. 67 shows a screenshot illustrating user interface(s) of the MLPO(e.g., HISTORICAL VS PANIC SIM);

FIG. 68 shows a screenshot illustrating user interface(s) of the MLPO(e.g., 3 M VIX THRESHOLDS VS UNPRECEDENTEDNESS (MSE) 3D);

FIG. 69 shows a screenshot illustrating user interface(s) of the MLPO(e.g., 6 M VIX THRESHOLDS VS UNPRECEDENTEDNESS (MSE) 3D);

FIG. 70 shows a screenshot illustrating user interface(s) of the MLPO(e.g., 1 Y VIX THRESHOLDS VS UNPRECEDENTEDNESS (MSE) 3D);

FIG. 71 shows a screenshot illustrating user interface(s) of the MLPO(e.g., CVaR FRONTIER COMPARISON WITH DIVERSIFITION OF 0.6 (LEFT) ANDDIVERSIFICATION OF 0.3 (RIGHT));

FIG. 72 shows a screenshot illustrating user interface(s) of the MLPO(e.g., TAIL RISK OPTIMIZATION RUNNING TIME COMPARISON OF INTEGERPROGRAMMING AND NON-INTEGER PROGRAMMING);

FIG. 73 shows a screenshot illustrating user interface(s) of the MLPO(e.g., EFFICIENT FRONTIER COMPARISON WITH RISK TOLERANCE OF 7 (LEFT) ANDRISK TOLERANCE OF 3 (RIGHT));

FIG. 74 shows a screenshot illustrating user interface(s) of the MLPO(e.g., EFFICIENT FRONTIER COMPARISON WITH DIVERSIFICATION OF 0.7 (LEFT)AND RISK DIVERSIFICATION OF 0.3 (RIGHT);

FIG. 75 shows a screenshot illustrating user interface(s) of the MLPO(e.g., EFFICIENT FRONTIER COMPARISON WITH VIX RANGE OF(−3500,5500)(LEFT) AND VIX RANGE OF (−1500,3000)(RIGHT));

FIG. 76 shows an architecture for the MLPO (e.g., FACTOR EXPOSUREGENERATION PSEUDO CODE);

FIG. 77 shows an architecture for the MLPO (e.g., ASSET SIMULATIONGENERATION PSEUDO CODE);

FIG. 78 shows an architecture for the MLPO (e.g., FACTOR EXPOSUREGENERATION CONCEPT DIAGRAM);

FIG. 79 shows an architecture for the MLPO (e.g., ASSET SIMULATIONGENERATION CONCEPT DIAGRAM);

FIG. 80 shows an architecture for the MLPO (e.g., CONVEXITY ADJUSTMENTPSEUDO CODE (STEP 1));

FIG. 81 shows an architecture for the MLPO (e.g., CONVEXITY ADJUSTMENTPSEUDO CODE (STEP 2));

FIG. 82 shows an architecture for the MLPO (e.g., OPTIONALITY ADJUSTMENTPSEUDO CODE);

FIG. 83 shows an architecture for the MLPO (e.g., REAL-TIME ASSETSIMULATION PSEUDO CODE);

FIG. 84 shows an architecture for the MLPO (e.g., REAL-TIME ASSETSIMULATION CONCEPT DIAGRAM (ORACLE RDS ON CLOUD));

FIG. 85 shows an architecture for the MLPO (e.g., MULTIPLE USER-DEFINEDSCENARIOS PSEUDO CODE);

FIG. 86 shows an architecture for the MLPO (e.g., MULTIPLE USER-DEFINEDSCENARIOS CONCEPT DIAGRAM);

FIG. 87 shows an architecture for the MLPO (e.g., ASSET SIMULATION ERDIAGRAM);

FIG. 88 shows an architecture for the MLPO (e.g., BOND LADDERCONSTRUCTION FLOW);

FIG. 89 shows an architecture for the MLPO (e.g., BOND LADDERCONSTRUCTION API INPUT SAMPLE);

FIG. 90 shows an architecture for the MLPO (e.g., BOND LADDERCONSTRUCTION API OUTPUT SAMPLE);

FIG. 91 shows an architecture for the MLPO (e.g., RISK ANALYSIS APIINPUT SAMPLE);

FIG. 92 shows an architecture for the MLPO (e.g., RISK ANALYSIS APIOUTPUT SAMPLE);

FIG. 93 shows a screenshot illustrating user interface(s) of the MLPO(e.g., BOND LADDER CONSTRUCTION USER INPUT/SELECTION SCREEN);

FIG. 94 shows a screenshot illustrating user interface(s) of the MLPO(e.g., BOND LADDER CONSTRUCTION—SAMPLE CORPORATE LADDER);

FIG. 95 shows a screenshot illustrating user interface(s) of the MLPO(e.g., BOND LADDER CONSTRUCTION—SAMPLE MUNI LADDER);

FIG. 96 shows a screenshot illustrating user interface(s) of the MLPO(e.g., BOND LADDER CONSTRUCTION—MAXIMIZE YIELD METHOD/OPTION);

FIG. 97 shows a screenshot illustrating user interface(s) of the MLPO(e.g., BOND LADDER CONSTRUCTION—RISK SCORE ADJUSTED METHOD/OPTION);

FIG. 98 shows a screenshot illustrating user interface(s) of the MLPO(e.g., MULTIPLE USER-DEFINED SCENARIOS—MARKET SENSITIVITY ANALYSIS);

FIG. 99 shows a block diagram illustrating embodiments of a MLPOcontroller.

Generally, the leading number of each citation number within thedrawings indicates the figure in which that citation number isintroduced and/or detailed. As such, a detailed discussion of citationnumber 101 would be found and/or introduced in FIG. 1. Citation number201 is introduced in FIG. 2, etc. Any citations and/or reference numbersare not necessarily sequences but rather just example orders that may berearranged and other orders are contemplated. Citation number suffixesmay indicate that an earlier introduced item has been re-referenced inthe context of a later figure and may indicate the same item,evolved/modified version of the earlier introduced item, etc., e.g.,server 199 of FIG. 1 may be a similar server 299 of FIG. 2 in the sameand/or new context.

DETAILED DESCRIPTION

The Machine Learning Portfolio Simulating and Optimizing Apparatuses,Methods and Systems (hereinafter “MLPO”) transforms machine learningsimulation request, decision tree ensembles training request, expectedreturns calculation request, portfolio construction request, predefinedscenario construction request, portfolio returns visualization requestinputs, via MLPO components (e.g., MLSSP, DTET, ERC, PC, PSC, SPRV,BPRV, PRV, ARMC, etc. components), into machine learning simulationresponse, decision tree ensembles training response, expected returnscalculation response, portfolio construction response, predefinedscenario construction response, portfolio returns visualization responseoutputs. The MLPO components, in various embodiments, implementadvantageous features as set forth below.

INTRODUCTION

The MLPO provides unconventional features (e.g., executing tradeabletransactions to create an optimized portfolio based on expected returnssimulated using machine learning techniques, a SQL database calculationengine) that were never before available in machine learning anddatabase systems.

Tail-events have rare historical occurrence. They are difficult to modeland forecast. However, they can be an essential part of resilientdecision processes. The MLPO demonstrates unique abilities to modelvariations in volatilities and dependency structures across factors andover different time periods; provides rich estimates of tail-event;enables conditional outcomes of tail-events; and uses advanced linearand non-linear optimization processes for superior decision support. Theoptimization results provide model recommended solutions, such as forportfolio construction.

The MLPO presents the latest innovations in two core capabilities ofinvestment management: 1) simulation driven investment insights anddecision support and 2) machine driven portfolio allocation guidance. Itcombines the latest machine learning methods with leading-edge cloudcomputing techniques. It enables differentiations across many businessunits: analytics and insights to power a commercial electronic bondtrading platform, power tools for evaluating portfolio constructionbias, smart Bond Ladder products, and/or the like.

In various embodiments, the MLPO may include one or more of thefollowing features:

1 Maximizes the usage of high frequency historical data

-   -   a. Machine learning processes to impute missing data (e.g., in        order to preserve higher frequency time-series data with gaps,        and maximize the utility of all available historical data)    -   b. Flexible periodicity with overlapping techniques

2. Combines a mixer of copulas, flexible marginal distributions,rejection sampling and parallel computing for a single simulation enginewhich

-   -   a. Models changes in correlations and volatilities for “fat        tail” events (e.g., using massive parallel computing to        concurrently perform simulation and/or conditional simulation        and/or stress scenario generations over cloud computing        infrastructure)    -   b. Generates insights on the conditional impact of diverse        factors on tail-events and volatilities

3. Allows calibration to forward-looking signals

4. Allows domain experts to incorporate their subjective views

5. Simulates longer horizon, multi-period outcomes with path dependency(e.g., using massive parallel computing frameworks in path-dependent,multi-period simulation to capture joint seasonality and mean-reversiontendencies across factors)

6. Preserves the cadence of historical cycles in forward-lookingsimulation paths

7. Allows forward-looking factor views to drive optimization results

8. Applies “simulation-data-driven” approach for tailed-constrainedportfolio optimization (e.g., to recommend solutions allowing tail-risk,tradability controls, etc.). In one embodiment, applies linearrelaxation to CVaR constraints and mixed integer linear programming foroptimization problem solving. In another embodiment, applies stochasticoptimizer with VaR or CVaR and integer constraints to solve a non-linearoptimization problem.

In some embodiments, the MLPO may implement a database calculationengine for calculating simulation data. The database calculation enginemay be a SQL-based solution that effectively utilizes different datareduction and parallel execution techniques to reduce the overallresponse time. Instead of using a dedicated high-performance platform(e.g., IBM Netezza Data Appliance) the database calculation engine maybe used for simulation calculation providing a faster, streamlined, costeffective and scalable solution (e.g., using Oracle RDS on Cloud) thatprovides calculation results in substantially less amount of time.Further, the database calculation engine eliminates having to maintain acomplex infrastructure and applications associated with using adedicated high-performance platform, and having to pay for additionallicensing and maintenance costs.

The database calculation engine solution is faster as data does not haveto be transferred outside of the database with an innovative datareduction strategy that applies to simulation generation, less complexas the solution may run entirely on a database, scalable as the solutioneffectively utilizes vertical scalability offered by RDS on Cloud andmore maintainable.

In some implementations, the database calculation engine may provide thefollowing features:

-   -   A novel way of calculating simulation data using a SQL only        solution.    -   Application of unique data reduction techniques applicable        specifically to the way data is aggregated for simulation data.    -   Use of vertical scalability and concurrency offered by Oracle        RDS on Cloud for faster execution.    -   Processing that happens at the database level, eliminating        having to transfer data outside to external systems and        maximizing processing of data using cloud computing.    -   Faster and more cost effective than using high-performance        platforms.

In some implementations, the database calculation engine may utilizevarious innovative data reduction, scaling and parallel computingtechniques (e.g., techniques to use global temporary tables andsessions, data reduction techniques to drastically reduce the amount ofdata used for processing thus lowering processing time, and severalother data parallelization techniques used for generating simulationdata):

-   -   Use of Multiple Batches to achieve higher degree of parallelism        (DOP)    -   Use of Global Temporary Tables (GTT) to be able to run batch in        multiple sessions and limit temporary storage requirements    -   Use of Data Reduction techniques to limit full table scans for        joins between Factor Exposure and Factor Simulation table    -   Use of Parallel Query to parallelize generation of Asset        Simulation and Contribution to Value at Risk data    -   Use of Parallel DML to parallelize inserting data related to        Asset Simulation and Contribution to Value at Risk    -   Use of DDL for faster execution of delete statements to speed up        cleanup of global temporary tables

MLPO

FIGS. 1A-B show a datagraph illustrating data flow(s) for the MLPO. InFIGS. 1A-B, an administrative client 102 (e.g., of an administrativeuser) may send a machine learning simulation request 121 to a MLPOserver 106 to facilitate generating a set of simulated scenarios (e.g.,a scenario may be a set of simulated market factor changes). Forexample, the administrative client may be a desktop, a laptop, a tablet,a smartphone, a smartwatch, and/or the like that is executing a clientapplication. In one implementation, the machine learning simulationrequest may include data such as a request identifier, configurationsettings, and/or the like. In one embodiment, the administrative clientmay provide the following example machine learning simulation request,substantially in the form of a (Secure) Hypertext Transfer Protocol(“HTTP(S)”) POST message including eXtensible Markup Language (“XML”)formatted data, as provided below:

POST /authrequest.php HTTP/1.1 Host: www.server.com Content-Type:Application/XML Content-Length: 667 <?XML version = “1.0” encoding =“UTF-8”?> <auth_request> <timestamp>2020-12-31 23:59:59</timestamp><user_accounts_details> <user_account_credentials><user_name>JohnDaDoeDoeDoooe@gmail.com</user_name><password>abc123</password> //OPTIONAL <cookie>cookieID</cookie>//OPTIONAL <digital_cert_link>www.mydigitalcertificate.com/JohnDoeDaDoeDoe@gmail.com/mycertifcate.dc</digital_cert_link> //OPTIONAL<digital_certificate>_DATA_</digital_certificate></user_account_credentials> </user_accounts_details> <client_details>//iOS Client with App and Webkit //it should be noted that althoughseveral client details //sections are provided to show example variantsof client //sources, further messages will include only on to save//space <client_IP>10.0.0.123</client_IP> <user_agent_string>Mozilla/5.0(iPhone; CPU iPhone OS 7_1_1 like Mac OS X) AppleWebKit/537.51.2 (KHTML,like Gecko) Version/7.0 Mobile/11D201 Safari/9537.53</user_agent_string><client_product_type>iPhone6,1</client_product_type><client_serial_number>DNXXX1X1XXXX</client_serial_number><client_UDID>3XXXXXXXXXXXXXXXXXXXXXXXXD</client_UDID><client_OS>iOS</client_OS> <client_OS_version>7.1.1</client_OS_version><client_app_type>app with webkit</client_app_type><app_installed_flag>true</app_installed_flag><app_name>MLPO.app</app_name> <app_version>1.0 </app_version><app_webkit_name>Mobile Safari</client_webkit_name><client_version>537.51.2</client_version> </client_details><client_details> //iOS Client with Webbrowser<client_IP>10.0.0.123</client_IP> <user_agent_string>Mozilla/5.0(iPhone; CPU iPhone OS 7_1_1 like Mac OS X) AppleWebKit/537.51.2 (KHTML,like Gecko) Version/7.0 Mobile/11D201 Safari/9537.53</user_agent_string><client_product_type>iPhone6,1</client_product_type><client_serial_number>DNXXX1X1XXXX</client_serial_number><client_UDID>3XXXXXXXXXXXXXXXXXXXXXXXXD</client_UDID><client_OS>iOS</client_OS> <client_OS_version>7.1.1</client_OS_version><client_app_type>web browser</client_app_type> <client_name>MobileSafari</client_name> <client_version>9537.53</client_version></client_details> <client_details> //Android Client with Webbrowser<client_IP>10.0.0.123</client_IP> <user_agent_string>Mozilla/5.0 (Linux;U; Android 4.0.4; en-us; Nexus S Build/IMM76D) AppleWebKit/534.30(KHTML, like Gecko) Version/4.0 Mobile Safari/534.30</user_agent_string><client_product_type>Nexus S</client_product_type><client_serial_number>YXXXXXXXXZ</client_serial_number><client_UDID>FXXXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXXX</client_UDID><client_OS>Android</client_OS><client_OS_version>4.0.4</client_OS_version> <client_app_type>webbrowser</client_app_type> <client_name>Mobile Safari</client_name><client_version>534.30</client_version> </client_details><client_details> //Mac Desktop with Webbrowser<client_IP>10.0.0.123</client_IP> <user_agent_string>Mozilla/5.0(Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.75.14 (KHTML, likeGecko) Version/7.0.3 Safari/537.75.14</user_agent_string><client_product_type>MacPro5,1</client_product_type><client_serial_number>YXXXXXXXXZ</client_serial_number><client_UDID>FXXXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXXX</client_UDID><client_OS>Mac OS X</client_OS><client_OS_version>10.9.3</client_OS_version> <client_app_type>webbrowser</client_app_type> <client_name>Mobile Safari</client_name><client_version>537.75.14</client_version> </client_details><machine_learning_simulation_request><request_identifier>ID_request_1</request_identifier><configuration_settings> <historical_data>last 30years</historical_data> <rolling_window_period_length>6months</rolling_window_period_length><time_period_bucket_type>FIXED</time_period_bucket_type><time_period_bucket_length>6 months</time_period_bucket_length><market_factors> ID_interest_rate_5Y, ID_oil_price, ID_credit_spread,ID_SP500 </market_factors><distribution_type>Gaussian</distribution_type><machine_learning_structure_type> deep learning neural network</machine_learning_structure_type> <hyper_parameters_to_test><hyper_parameters_option><option_identifier>ID_option_1</option_identifier> <encoder>3 layers,100 perceptrons each</encoder> <latent_space>50 variables</latent_space><decoder>3 layers, 100 perceptrons each</decoder></hyper_parameters_option> <hyper_parameters_option><option_identifier>ID_option_2</option_identifier> <encoder>4 layers, 80perceptrons each</encoder> <latent_space>60 variables</latent_space><decoder>4 layers, 80 perceptrons each</decoder></hyper_parameters_option> ... </hyper_parameters_to_test><number_of_simulated_market_scenarios> 1000 scenarios per time periodbucket </number_of_simulated_market_scenarios> </configuration_settings></machine_learning_simulation_request> </auth_request>

A machine learning simulated scenario processing (MLSSP) component 123may utilize data provided in the machine learning simulation request totrain a machine learning structure and/or to generate a set of simulatedscenarios. See FIGS. 2A-B and FIG. 4 for additional details regardingthe MLSSP component.

The MLPO server 106 may send a scenario results store request 125 to arepository 110 to facilitate storing the generated set of simulatedscenarios (e.g., a simulation) in a database. In one implementation, thescenario results store request may include data such as a requestidentifier, a simulation identifier, simulated scenarios, and/or thelike. In one embodiment, the MLPO server may provide the followingexample scenario results store request, substantially in the form of aHTTP(S) POST message including XML-formatted data, as provided below:

POST /scenario_results_store_request.php HTTP/1.1 Host: www.server.comContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <scenario_results_store_request><request_identifier>ID_request_2</request_identifier><simulation_identifier>ID_sim_1</simulation_identifier><simulated_scenarios> <scenario><scenario_identifier>ID_scenario_1</scenario_identifier> <market_factor><market_factor_identifier>ID_interest_rate_5Y</market_factor_identifier><market_factor_change>25 basis points</market_factor_change></market_factor> <market_factor><market_factor_identifier>ID_oil_price</market_factor_identifier><market_factor_change>$10</market_factor_change> </market_factor> ...</scenario> <scenario><scenario_identifier>ID_scenario_2</scenario_identifier> <market_factor><market_factor_identifier>ID_interest_rate_5Y</market_factor_identifier><market_factor_change>50 basis points</market_factor_change></market_factor> <market_factor><market_factor_identifier>ID_oil_price</market_factor_identifier><market_factor_change>$15</market_factor_change> </market_factor> ...</scenario> ... </simulated_scenarios> </scenario_results_store_request>

The repository 110 may send a scenario results store response 127 to theMLPO server 106 to confirm that the generated set of simulated scenarioswas stored successfully. In one implementation, the scenario resultsstore response may include data such as a response identifier, a status,and/or the like. In one embodiment, the repository may provide thefollowing example scenario results store response, substantially in theform of a HTTP(S) POST message including XML-formatted data, as providedbelow:

POST /scenario_results_store_response.php HTTP/1.1 Host: www.server.comContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <scenario_results_store_response><response_identifier>ID_response_2</response_identifier><status>OK</status> </scenario_results_store_response>

The MLPO server 106 may send a machine learning simulation response 129to the administrative client 102 to inform the administrative user thata set of simulated scenarios was generated successfully. In oneimplementation, the machine learning simulation response may includedata such as a response identifier, a status, and/or the like. In oneembodiment, the MLPO server may provide the following example machinelearning simulation response, substantially in the form of a HTTP(S)POST message including XML-formatted data, as provided below:

POST /machine_learning_simulation_response.php HTTP/1.1 Host:www.server.com Content-Type: Application/XML Content-Length: 667 <?XMLversion = “1.0” encoding = “UTF-8”?><machine_learning_simulation_response><response_identifier>ID_response_1</response_identifier><status>OK</status> </machine_learning_simulation_response>

The administrative client 102 may send a decision tree ensemblestraining request 131 to the MLPO server 106 to facilitate trainingdecision tree ensembles for a universe of securities. For example,different decision tree ensembles may be trained for each security fordifferent predictive capabilities (e.g., one decision tree ensemble maybe trained to estimate conditional Beta for a security, and anotherdecision tree ensemble may be trained to estimate conditional defaultfor the security). In one implementation, the decision tree ensemblestraining request may include data such as a request identifier, auniverse of securities, predictive capabilities configuration, trainingfeatures configuration, and/or the like. In one embodiment, theadministrative client may provide the following example decision treeensembles training request, substantially in the form of a HTTP(S) POSTmessage including XML-formatted data, as provided below:

POST /decision_tree_ensembles_training_request.php HTTP/1.1 Host:www.server.com Content-Type: Application/XML Content-Length: 667 <?XMLversion = “1.0” encoding = “UTF-8”?><decision_tree_ensembles_training_request><request_identifier>ID_request_3</request_identifier><universe_of_securities>Securities in S&P 500</universe_of_securities><predictive_capabilities_configuration> <predictive_capability><predictive_capability_type>ConditionalBeta</predictive_capability_type> <training_features> <feature>ratio ofcash to market value of total assets</feature> <feature>ratio of netincome to total assets</feature> <feature>size measure</feature><feature>sector dummy variable</feature> ... </training_features></predictive_capability> <predictive_capability><predictive_capability_typeConditionalDefault</predictive_capability_type> <training_features> <feature>ratioof cash to market value of total assets</feature> <feature>unemploymentrate</feature> <feature>value of VIX index</feature> ...</training_features> </predictive_capability></predictive_capabilities_configuration></decision_tree_ensembles_training_request>

A decision tree ensembles training (DTET) component 133 may utilize dataprovided in the decision tree ensembles training request to traindecision tree ensembles for the universe of securities. See FIG. 5 foradditional details regarding the DTET component.

The MLPO server 106 may send a decision tree ensembles store request 135to the repository 110 to facilitate storing the trained decision treeensembles. In one implementation, the decision tree ensembles storerequest may include data such as a request identifier, decision treeensembles, and/or the like. In one embodiment, the MLPO server mayprovide the following example decision tree ensembles store request,substantially in the form of a HTTP(S) POST message includingXML-formatted data, as provided below:

POST /decision_tree_ensembles_store_request.php HTTP/1.1 Host:www.server.com Content-Type: Application/XML Content-Length: 667 <?XMLversion = “1.0” encoding = “UTF-8”?><decision_tree_ensembles_store_request><request_identifier>ID_request_4</request_identifier><decision_tree_ensembles> <decision_tree_ensemble><decision_tree_ensemble_id>ID_DTE_1</decision_tree_ensemble_id><associated_security>MSFT</associated_security><predictive_capability_type>ConditionalBeta</predictive_capability_type> <decision_tree_ensemble_data> decisiontree ensemble datastructure </decision_tree_ensemble_data></decision_tree_ensemble> <decision_tree_ensemble><decision_tree_ensemble_id>ID_DTE_2</decision_tree_ensemble_id><associated_security>MSFT</associated_security><predictive_capability_type>ConditionalDefault</predictive_capability_type> <decision_tree_ensemble_data>decision tree ensemble datastructure </decision_tree_ensemble_data></decision_tree_ensemble><decision_tree_ensemble_id>ID_DTE_3</decision_tree_ensemble_id><associated_security>AAPL</associated_security><predictive_capability_type>ConditionalBeta</predictive_capability_type> <decision_tree_ensemble_data> decisiontree ensemble datastructure </decision_tree_ensemble_data></decision_tree_ensemble> <decision_tree_ensemble><decision_tree_ensemble_id>ID_DTE_4</decision_tree_ensemble_id><associated_security>AAPL</associated_security><predictive_capability_typeConditionalDefault</predictive_capability_type> <decision_tree_ensemble_data>decision tree ensemble datastructure </decision_tree_ensemble_data></decision_tree_ensemble> ... </decision_tree_ensembles></decision_tree_ensembles_store_request>

The repository 110 may send a decision tree ensembles store response 137to the MLPO server 106 to confirm that the trained decision treeensembles were stored successfully. In one implementation, the decisiontree ensembles store response may include data such as a responseidentifier, a status, and/or the like. In one embodiment, the repositorymay provide the following example decision tree ensembles storeresponse, substantially in the form of a HTTP(S) POST message includingXML-formatted data, as provided below:

POST /decision_tree_ensembles_store_response.php HTTP/1.1 Host:www.server.com Content-Type: Application/XML Content-Length: 667 <?XMLversion = “1.0” encoding = “UTF-8”?><decision_tree_ensembles_store_response><response_identifier>ID_response_4</response_identifier><status>OK</status> </decision_tree_ensembles_store_response>

The MLPO server 106 may send a decision tree ensembles training response139 to the administrative client 102 to inform the administrative userthat decision tree ensembles were trained successfully. In oneimplementation, the decision tree ensembles training response mayinclude data such as a response identifier, a status, and/or the like.In one embodiment, the MLPO server may provide the following exampledecision tree ensembles training response, substantially in the form ofa HTTP(S) POST message including XML-formatted data, as provided below:

POST /decision_tree_ensembles_training_response.php HTTP/1.1 Host:www.server.com Content-Type: Application/XML Content-Length: 667 <?XMLversion = “1.0” encoding = “UTF-8”?><decision_tree_ensembles_training_response><response_identifier>ID_response_3</response_identifier><status>OK</status> </decision_tree_ensembles_training_response>

The administrative client 102 may send an expected returns calculationrequest 141 to the MLPO server 106 to facilitate calculating expectedreturns for the universe of securities under the simulated scenarios. Inone implementation, the expected returns calculation request may includedata such as a request identifier, a universe of securities, asimulation identifier, a set of simulated scenarios, and/or the like. Inone embodiment, the administrative client may provide the followingexample expected returns calculation request, substantially in the formof a HTTP(S) POST message including XML-formatted data, as providedbelow:

POST /expected_returns_calculation_request.php HTTP/1.1 Host:www.server.com Content-Type: Application/XML Content-Length: 667 <?XMLversion = “1.0” encoding = “UTF-8”?><expected_returns_calculation_request><request_identifier>ID_request_5</request_identifier><universe_of_securities>Securities in S&P 500</universe_of_securities><simulation_identifier>ID_sim_1</simulation_identifier><simulated_scenarios>ID_scenario_1, ID_scenario_2,...</simulated_scenarios> </expected_returns_calculation_request>

The MLPO server 106 may send a scenario results retrieve request 145 tothe repository 110 to facilitate retrieving simulated market factorchanges for a simulated scenario. In one implementation, the scenarioresults retrieve request may include data such as a request identifier,a simulation identifier, a scenario identifier, and/or the like. In oneembodiment, the MLPO server may provide the following example scenarioresults retrieve request, substantially in the form of a HTTP(S) POSTmessage including XML-formatted data, as provided below:

POST /scenario_results_retrieve_request.php HTTP/1.1 Host:www.server.com Content-Type: Application/XML Content-Length: 667 <?XMLversion = “1.0” encoding = “UTF-8”?> <scenario_results_retrieve_request><request_identifier>ID_request_6</request_identifier><simulation_identifier>ID_sim_1</simulation_identifier><scenario_identifier>ID_scenario_1</scenario_identifier></scenario_results_retrieve_request>

The repository 110 may send a scenario results retrieve response 147 tothe MLPO server 106 with the requested simulated market factor changesdata. In one implementation, the scenario results retrieve response mayinclude data such as a response identifier, the requested simulatedmarket factor changes data, and/or the like. In one embodiment, therepository may provide the following example scenario results retrieveresponse, substantially in the form of a HTTP(S) POST message includingXML-formatted data, as provided below:

POST /scenario_results_retrieve_response.php HTTP/1.1 Host:www.server.com Content-Type: Application/XML Content-Length: 667 <?XMLversion = “1.0” encoding = “UTF-8”?><scenario_results_retrieve_response><response_identifier>ID_response_6</response_identifier> <scenario_data><market_factor><market_factor_identifier>ID_interest_rate_5Y</market_factor_identifier><market_factor_change>25 basis points</market_factor_change></market_factor> <market_factor><market_factor_identifier>ID_oil_price</market_factor_identifier><market_factor_change>$10</market_factor_change> </market_factor> ...</scenario_data> </scenario_results_retrieve_response>

An expected returns calculation (ERC) component 149 may utilize dataprovided in the expected returns calculation request, data provided inthe scenario results retrieve response, and/or the trained decision treeensembles to calculate expected returns for the universe of securitiesunder the simulated scenarios. See FIG. 7A for additional detailsregarding the ERC component.

The MLPO server 106 may send an expected returns store request 151 tothe repository 110 to facilitate storing the calculated expectedreturns. In one implementation, the expected returns store request mayinclude data such as a request identifier, expected returns, and/or thelike. In one embodiment, the MLPO server may provide the followingexample expected returns store request, substantially in the form of aHTTP(S) POST message including XML-formatted data, as provided below:

POST /expected_returns_store_request.php HTTP/1.1 Host: www.server.comContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <expected_returns_store_request><request_identifier>ID_request_7</request_identifier> <expected_returns><simulation_identifier>ID_sim_1</simulation_identifier> <scenario><scenario_identifier>ID_scenario_1</scenario_identifier> <security><security_identifier>MSFT</security_identifier><expected_return>10%</expected_return> </security> <security><security_identifier>AAPL</security_identifier><expected_return>12%</expected_return> </security> ... </scenario><scenario> <scenario_identifier>ID_scenario_2</scenario_identifier><security> <security_identifier>MSFT</security_identifier><expected_return>15%</expected_return> </security> <security><security_identifier>AAPL</security_identifier><expected_return>13%</expected_return> </security> ... </scenario> ...</expected_returns> </expected_returns_store_request>

The repository 110 may send an expected returns store response 153 tothe MLPO server 106 to confirm that the calculated expected returns werestored successfully. In one implementation, the expected returns storeresponse may include data such as a response identifier, a status,and/or the like. In one embodiment, the repository may provide thefollowing example expected returns store response, substantially in theform of a HTTP(S) POST message including XML-formatted data, as providedbelow:

POST /expected_returns_store_response.php HTTP/1.1 Host: www.server.comContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <expected_returns_store_response><response_identifier>ID_response_7</response_identifier><status>OK</status> </expected_returns_store_response>

The MLPO server 106 may send an expected returns calculation response155 to the administrative client 102 to inform the administrative userthat expected returns for the universe of securities under the simulatedscenarios were calculated successfully. In one implementation, theexpected returns calculation response may include data such as aresponse identifier, a status, and/or the like. In one embodiment, theMLPO server may provide the following example expected returnscalculation response, substantially in the form of a HTTP(S) POSTmessage including XML-formatted data, as provided below:

POST /expected_returns_calculation_response.php HTTP/1.1 Host:www.server.com Content-Type: Application/XML Content-Length: 667 <?XMLversion = “1.0” encoding = “UTF-8”?><expected_returns_calculation_response><response_identifier>ID_response_5</response_identifier><status>OK</status> </expected_returns_calculation_response>

FIGS. 2A-B show a logic flow illustrating embodiments of a machinelearning simulated scenario processing (MLSSP) component for the MLPO.In FIG. 2A, a machine learning simulated scenario processing request maybe obtained at 201. For example, the machine learning simulated scenarioprocessing request may be obtained as a result of an administrative userrequesting generation of a set of simulated scenarios.

A rolling window period length may be determined at 205. In oneembodiment, historical data may be analyzed to calculate changes to aset of market factors during each rolling window period of a specifiedrolling window period length. In one implementation, the machinelearning simulated scenario processing request may be parsed (e.g.,using PHP commands) to determine historical data to analyze (e.g., basedon the value of the historical_data_field) and/or the rolling windowperiod length to use for analysis (e.g., based on the value of therolling_window_period_length field). For example, the machine learningsimulated scenario processing request may specify that the last 30 yearsof historical data should be analyzed using 6 month rolling windowperiods.

Market factors to process may be determined at 209. For example, marketfactors may include interest rates, credit spread, oil price, equityindices, and/or the like, and changes to the market factors during arolling window period jointly describe a market scenario (e.g., ahistorical market scenario for historical changes, a simulated marketscenario for simulated changes). In one implementation, the machinelearning simulated scenario processing request may be parsed (e.g.,using PHP commands) to determine the market factors to process (e.g.,based on the value of the market_factors field). In anotherimplementation, a set of default market factors to process may bespecified in a configuration setting.

A determination may be made at 213 whether there remain market factorsto process. In one implementation, each of the market factors may beprocessed. If there remain market factors to process, the next marketfactor (e.g., 6 month change in interest rates) may be selected forprocessing at 217.

A determination may be made at 221 whether there remain rolling windowperiods to analyze. In one implementation, historical data for theselected market factor may be analyzed during each of the rolling windowperiods. If there remain rolling window periods to analyze, the nextrolling window period may be selected for analysis at 225. For example,the next rolling window period may be two specific time points (e.g.,days) 6 months apart.

A determination may be made at 229 whether data for the selected rollingwindow period is available. In one implementation, this determinationmay be made based on whether historical data for the selected marketfactor is available for both time points (e.g., for both days) of theselected rolling window period.

If historical market factor data is unavailable for one or both timepoints (e.g., days) of the selected rolling window period, the missingdata may be imputed using a machine learning (e.g., k-Nearest Neighbors(k-NN)) method at 233 based on market factor data for other time points(e.g., for other days). In one implementation, the k-NN method may beused to match records (e.g., a record may be a set of market factors fora time point) with missing data points (e.g., a missing data point maybe a missing market factor data for a time point) in a multi-dimensionalspace. For example, the missing data for the selected market factor fora time point may be calculated as the average of values of the selectedmarket factor for k nearest neighbors of the time point as determinedbased on similarity of the other market factors.

Change to the selected market factor during the selected rolling windowperiod may be calculated at 237. In one implementation, the change tothe selected market factor during the selected rolling window period maybe calculated by determining the delta between values of the selectedmarket factor at the two time points of the selected rolling windowperiod. For example, the 6 month change in 5 year interest rates for therolling window period between Jan. 7, 2019 and Jul. 8, 2019, may becalculated by subtracting the US Treasury 5 Year Par Yield on Jan. 7,2019 from the US Treasury 5 Year Par Yield on Jul. 8, 2019. In anotherexample, the 6 month change in 5 year interest rates for the rollingwindow period between Jan. 8, 2019 and Jul. 9, 2019, may be calculatedby subtracting the US Treasury 5 Year Par Yield on Jan. 8, 2019 from theUS Treasury 5 Year Par Yield on Jul. 9, 2019.

Once changes to each of the market factors during each of the rollingwindow periods are calculated, a determination may be made at 241regarding the type of time period buckets to utilize. In one embodiment,fixed length time period buckets may be utilized. In another embodiment,variable length time period buckets may be utilized. In oneimplementation, the machine learning simulated scenario processingrequest may be parsed (e.g., using PHP commands) to determine the typeof time period buckets to utilize (e.g., based on the value of thetime_period_bucket_type field).

If fixed length time period buckets are utilized, the length of timeperiod buckets to utilize may be determined at 245. In oneimplementation, the machine learning simulated scenario processingrequest may be parsed (e.g., using PHP commands) to determine the lengthof time period buckets to utilize (e.g., based on the value of thetime_period_bucket_length field). For example, the machine learningsimulated scenario processing request may specify that historical marketscenarios generated from the last 30 years of historical data (e.g.,using calculated changes from 237) should be split using 6 month longtime period buckets, resulting in 60 time period buckets to process. Itis to be understood that the length of time period buckets isindependent of the rolling window period length (e.g., the two lengthsmay be the same or may be different).

If variable length time period buckets are utilized, time period bucketsreflective of changes in volatilities and correlations of the historicaldata may be determined at 249. In one implementation, the time periodbuckets may be selected by judging the overall goodness of fit betweensimulated data from the time period buckets and historical data. KStests and Cramer test may be performed jointly between the simulatedmarket scenarios and the historical market scenarios. The splitting intotime period buckets may support the objective function of minimizing theKS test values of the marginal distributions and Cramer test value ofthe multivariate distribution of simulated market scenarios vs. realizedhistorical market scenarios. For example, the machine learning simulatedscenario processing request may specify that historical market scenariosgenerated from the last 30 years of historical data (e.g., usingcalculated changes from 237) should be split by bucketing historicalmarket scenarios from the same economic cycle (e.g., early cycle, midcycle, late cycle, recession) together to summarize the changes involatilities and correlation structure. In some implementations, thenumber of time period buckets may be determined by balancing the amountof historical data vs. the number of market factors. For example, giventhat data frequency is constant, as the number of market factorsincreases the time duration utilized for each time period bucketincreases.

The historical market scenarios may be bucketed in accordance with thedetermined time period buckets at 253. In one implementation, eachhistorical market scenario may be assigned a bucket identifier thatspecifies the time period bucket associated with the respectivehistorical market scenario.

A determination may be made at 257 whether there remain time periodbuckets to process. In one implementation, each of the time periodbuckets may be processed. If there remain time period buckets toprocess, the next time period bucket (e.g., historical market scenariosassociated with the next 6 month long time period bucket) may beselected for processing at 261.

A deep learning neural network for the selected time period bucket maybe trained at 281. For example, the deep learning neural network may bea Gaussian-Mixture Variational Autoencoder. In one embodiment, the deeplearning neural network may be trained to map historical market factorchanges to latent space variables and/or to map latent space variablesto simulated market factor changes. See FIG. 2B for additional detailsregarding training the deep learning neural network. See FIG. 3 for anexemplary deep learning neural network architecture.

The number of market scenarios to simulate may be determined at 289. Forexample, 1,000 scenarios may be simulated (e.g., resulting in 60,000total simulated scenarios over 60 time period buckets). In oneimplementation, the machine learning simulated scenario processingrequest may be parsed (e.g., using PHP commands) to determine the numberof market scenarios to simulate for each of the time period buckets(e.g., based on the value of the number_of_simulated_market_scenariosfield). In another implementation, the number of market scenarios tosimulate for each of the time period buckets may be specified in aconfiguration setting. In another implementation, the number of marketscenarios to simulate may differ for different time period buckets. Forexample, the number of market scenarios to simulate may be determined asan AI-driven weight learned by minimizing the L2 Norm between real dataand simulated data.

A determination may be made at 293 whether there remain market scenariosto simulate. If so, simulated data may be generated using latent spacevariables at 295. In one implementation, random values for latent spacevariables of the trained deep learning neural network may be generated.For example, a random value for a latent space variable of the traineddeep learning neural network may be generated (e.g., by optimizing thenumber of perceptrons, the number of layers of the encoder and decoderneural networks, and/or the number of latent space variables with theobjective function of minimizing the L2 Norm between generated marketfactor changes and historical market factor changes) from a Gaussian orGaussian mixture distribution (e.g., from a multivariate Gaussiandistribution) using the Python NumPy library (e.g., with three inputsincluding the number of samples to be generated, mean and variance fromthe encoder).

A set of simulated market factor changes may be generated from thesimulated data using a neural network decoder of the trained deeplearning neural network at 297. In one implementation, the generatedrandom values of latent space variables may be fed through the neuralnetwork decoder of the trained deep learning neural network to obtain aset of simulated market factor changes (e.g., the set of simulatedmarket factor changes may be referred to as a simulated marketscenario).

The simulated scenario may be stored in a database at 299. In oneimplementation, the simulated scenario may be stored (e.g., in a batchwith other simulated scenarios) via a scenario results store request.

FIG. 2B shows additional details regarding training the deep learningneural network. In FIG. 2B, the historical market scenarios (e.g., a setof calculated market factor changes for each rolling window period ofthe selected time period bucket) may be obtained at 202. In oneimplementation, a reference to a historical market factor changes datastructure (e.g., an array of arrays where each element of the outerarray corresponds to a training data point of historical market factorchanges for a rolling window period, and each element of the inner arraycorresponds to a historical return of a market factor during the rollingwindow period) with the calculated historical market factor changes maybe obtained.

A determination may be made at 206 whether there remain hyper-parametersoptions of the deep learning neural network to analyze. For example, thehyper-parameters of the deep learning neural network may include thenumber of layers and/or perceptrons in each layer of encoder and/ordecoder, the dimensionality of latent space, and/or the like. In oneimplementation, the machine learning simulated scenario processingrequest may be parsed (e.g., using PHP commands) to determinehyper-parameters options to test (e.g., based on the value of thehyper_parameters_to_test field). If there remain hyper-parametersoptions to analyze, the next set of hyper-parameters (e.g., specified ina hyper_parameters_option field) for the deep learning neural networkmay be selected for testing at 210.

A determination may be made at 212 whether a termination condition fortraining the deep learning neural network has been reached. In variousimplementations, the termination condition may comprise one or more of aspecified number of training iterations, a specified training time, aspecified minimum deep learning neural network performance rank, and/orthe like.

If the termination condition for training the deep learning neuralnetwork has not been reached, a determination may be made at 214 whetherthere remain more training data points to use for training the deeplearning neural network. In one implementation, each of the trainingdata points in the historical market factor changes data structure maybe used for training. If there remain more training data points to use,the next training data point (e.g., historical market factor changes fora rolling window period) may be selected at 218.

Input and output layers of the deep learning neural network may be setto the selected training data point at 222. In one implementation, theinput and output layers may be f-dimensional layers, where f is thenumber of market factors. For example, the input and output layers maybe set to the values of the inner array of the historical market factorchanges data structure corresponding to the selected training datapoint.

The deep learning neural network may be trained on the selected trainingdata point using a variational autoencoder to generate a set ofGaussian-Mixture latent variables at 226. In one embodiment, the deeplearning neural network may be trained using backpropagation with aspecified loss function. In one implementation, the loss function may bechosen to minimize mean squared error of the Euclidean distances ofindividual market factors return values to the historical realizedreturn values, and/or to minimize the variance of joint distributionsacross encoded market factors between simulated and historical marketsin the latent space (e.g., the KT, divergence score). In one embodiment,the loss function on factor returns may be in the original factor space,while the KT, divergence constraint plays the role in the latent space(lower dimensional space) to map the encoded factors to Gaussian orGaussian mixture distribution. In one implementation, the encoder andthe decoder may be set to have the same structures and during thetraining process their weights may be synchronized, so that half of thetotal weights have to be learned to reduce the complexity of deepnetwork training

Once the deep learning neural network is trained on the training datapoints, performance of the trained deep learning neural network may beevaluated at 230. For example, the performance of the trained deeplearning neural network may be evaluated using a set of testing datapoints (e.g., available data points may be split into 75% training datapoints and 25% testing data points). In one embodiment, the trained deeplearning neural network may be assigned a performance rank (e.g., ascore). In one implementation, differences between market factor changesat the input layer and market factor changes at the output layer may beevaluated using the Kolmogorov-Smirnov (KS) test for individual marketfactors and/or Cramer test for joint distribution to calculate aperformance score for the trained deep learning neural network. Forexample, for the KS test and/or the Cramer test, the lower the scores,the better the performance. Accordingly, the scores may be sorted inascending order and performance of deep learning neural networks may beranked in the hyperparameter tuning process such that the deep learningneural network with the optimal performance is the one with the highestrank.

If the termination condition for training the deep learning neuralnetwork has been reached, the next set of hyper-parameters, if any, forthe deep learning neural network may be analyzed at 206.

The neural network with the optimal performance may be selected at 234.In one implementation, the deep learning neural network with the best(e.g., highest) performance rank may be selected to simulate marketscenarios.

FIG. 3 shows an architecture for the MLPO. In FIG. 3, an embodiment ofhow a deep learning neural network may be structured is illustrated. Thedeep learning neural network may have an input layer 301. The inputlayer may be an f-dimensional layer, where f is the number of marketfactors. Market factor changes data provided to the input layer may beconverted using an encoder 305 into latent space variables 310. Theencoder may comprise one or more hidden layers, and the number of hiddenlayers and/or the number of perceptrons in each layer may behyper-parameters tuned for optimal performance. The latent spacevariables may comprise a hidden layer of Gaussian mixtures, and thedimensionality of latent space may be a hyper-parameter tuned foroptimal performance. In one embodiment, the latent space may beimplemented using a Gaussian distribution and a mixture layer. Themixture layer may be designed to introduce richer correlations acrossencoded factors and thus approximately formulate a Gaussian mixturedistribution. The simulation may be conducted by sampling from theGaussian distribution, then the samples may be transferred to a nearGaussian mixture space via the mixture layer, and then sent to a decoderthat maps to the original factor space. In another embodiment, thelatent space may be implemented using a standard Gaussian mixturedistribution (GM), where the mixture weights are hyper-parameters to befine-tuned. The simulation may be conducted by sampling from the GM, andthen the samples may be sent to a decoder. Latent space variables datamay be converted using a decoder 315 into market factor changes data inan output layer 320. The decoder may comprise one or more hidden layers,and the number of hidden layers and/or the number of perceptrons in eachlayer may be hyper-parameters tuned for optimal performance. The outputlayer may be an f-dimensional layer, where f is the number of marketfactors.

FIG. 4 shows a logic flow illustrating embodiments of a machine learningsimulated scenario processing (MLSSP) component for the MLPO. In FIG. 4,a machine learning simulated scenario processing request may be obtainedat 401. For example, the machine learning simulated scenario processingrequest may be obtained as a result of an administrative user requestinggeneration of a set of simulated scenarios.

A rolling window period length may be determined at 405. In oneembodiment, historical data may be analyzed to calculate changes to aset of market factors during each rolling window period of a specifiedrolling window period length. In one implementation, the machinelearning simulated scenario processing request may be parsed (e.g.,using PHP commands) to determine historical data to analyze (e.g., basedon the value of the historical_data_field) and/or the rolling windowperiod length to use for analysis (e.g., based on the value of therolling_window_period_length field). For example, the machine learningsimulated scenario processing request may specify that the last 30 yearsof historical data should be analyzed using 6 month rolling windowperiods.

Market factors to process may be determined at 409. For example, marketfactors may include interest rates, credit spread, oil price, equityindices, and/or the like, and changes to the market factors during arolling window period jointly describe a market scenario (e.g., ahistorical market scenario for historical changes, a simulated marketscenario for simulated changes). In one implementation, the machinelearning simulated scenario processing request may be parsed (e.g.,using PHP commands) to determine the market factors to process (e.g.,based on the value of the market_factors field). In anotherimplementation, a set of default market factors to process may bespecified in a configuration setting.

A determination may be made at 413 whether there remain market factorsto process. In one implementation, each of the market factors may beprocessed. If there remain market factors to process, the next marketfactor (e.g., 6 month change in interest rates) may be selected forprocessing at 417.

A determination may be made at 421 whether there remain rolling windowperiods to analyze. In one implementation, historical data for theselected market factor may be analyzed during each of the rolling windowperiods. If there remain rolling window periods to analyze, the nextrolling window period may be selected for analysis at 425. For example,the next rolling window period may be two specific time points (e.g.,days) 6 months apart.

A determination may be made at 429 whether data for the selected rollingwindow period is available. In one implementation, this determinationmay be made based on whether historical data for the selected marketfactor is available for both time points (e.g., for both days) of theselected rolling window period.

If historical market factor data is unavailable for one or both timepoints (e.g., days) of the selected rolling window period, the missingdata may be imputed using a machine learning (e.g., k-Nearest Neighbors(k-NN)) method at 433 based on market factor data for other time points(e.g., for other days). In one implementation, the k-NN method may beused to match records (e.g., a record may be a set of market factors fora time point) with missing data points (e.g., a missing data point maybe a missing market factor data for a time point) in a multi-dimensionalspace. For example, the missing data for the selected market factor fora time point may be calculated as the average of values of the selectedmarket factor for k nearest neighbors of the time point as determinedbased on similarity of the other market factors.

Change to the selected market factor during the selected rolling windowperiod may be calculated at 437. In one implementation, the change tothe selected market factor during the selected rolling window period maybe calculated by determining the delta between values of the selectedmarket factor at the two time points of the selected rolling windowperiod. For example, the 6 month change in 5 year interest rates for therolling window period between Jan. 7, 2019 and Jul. 8, 2019, may becalculated by subtracting the US Treasury 5 Year Par Yield on Jan. 7,2019 from the US Treasury 5 Year Par Yield on Jul. 8, 2019. In anotherexample, the 6 month change in 5 year interest rates for the rollingwindow period between Jan. 8, 2019 and Jul. 9, 2019, may be calculatedby subtracting the US Treasury 5 Year Par Yield on Jan. 8, 2019 from theUS Treasury 5 Year Par Yield on Jul. 9, 2019.

Once changes to each of the market factors during each of the rollingwindow periods are calculated, a determination may be made at 441regarding the type of time period buckets to utilize. In one embodiment,fixed length time period buckets may be utilized. In another embodiment,variable length time period buckets may be utilized. In oneimplementation, the machine learning simulated scenario processingrequest may be parsed (e.g., using PHP commands) to determine the typeof time period buckets to utilize (e.g., based on the value of thetime_period_bucket_type field).

If fixed length time period buckets are utilized, the length of timeperiod buckets to utilize may be determined at 445. In oneimplementation, the machine learning simulated scenario processingrequest may be parsed (e.g., using PHP commands) to determine the lengthof time period buckets to utilize (e.g., based on the value of thetime_period_bucket_length field). For example, the machine learningsimulated scenario processing request may specify that historical marketscenarios generated from the last 30 years of historical data (e.g.,using calculated changes from 437) should be split using 6 month longtime period buckets, resulting in 60 time period buckets to process. Itis to be understood that the length of time period buckets isindependent of the rolling window period length (e.g., the two lengthsmay be the same or may be different).

If variable length time period buckets are utilized, time period bucketsreflective of changes in volatilities and correlations of the historicaldata may be determined at 449. In one implementation, the time periodbuckets may be selected by judging the overall goodness of fit betweensimulated data from the time period buckets and historical data. KStests and Cramer test may be performed jointly between the simulatedmarket scenarios and the historical market scenarios. The splitting intotime period buckets may support the objective function of minimizing theKS test values of the marginal distributions and Cramer test value ofthe multivariate distribution of simulated market scenarios vs. realizedhistorical market scenarios. For example, the machine learning simulatedscenario processing request may specify that historical market scenariosgenerated from the last 30 years of historical data (e.g., usingcalculated changes from 437) should be split by bucketing historicalmarket scenarios from the same economic cycle (e.g., early cycle, midcycle, late cycle, recession) together to summarize the changes involatilities and correlation structure. In some implementations, thenumber of time period buckets may be determined by balancing the amountof historical data vs. the number of market factors. For example, giventhat data frequency is constant, as the number of market factorsincreases the time duration utilized for each time period bucketincreases.

The historical market scenarios may be bucketed in accordance with thedetermined time period buckets at 453. In one implementation, eachhistorical market scenario may be assigned a bucket identifier thatspecifies the time period bucket associated with the respectivehistorical market scenario.

A determination may be made at 457 whether there remain time periodbuckets to process. In one implementation, each of the time periodbuckets may be processed. If there remain time period buckets toprocess, the next time period bucket (e.g., historical market scenariosassociated with the next 6 month long time period bucket) may beselected for processing at 461.

A determination may be made at 465 whether there remain market factorsto process. In one implementation, each of the market factors may beprocessed. If there remain market factors to process, the next marketfactor (e.g., 6 month change in interest rates) may be selected forprocessing at 469.

A distribution to use for the selected market factor during the selectedtime period bucket may be determined using the selected market factor'sgoodness of fit at 473. For example, a distribution to use may beGaussian, log-normal, and/or the like. In one implementation, goodnessof fit calculation may be performed to determine which distribution fitsthe historical returns (e.g., the calculated changes) for each timebucket using Kolmogorov-Smirnov Test (KS test) and/or Cramer test. Forexample, the distribution to use may be determined as the one with thebest KS test performance for each of the individual factor and/or Cramertest performance for the overall distribution.

The determined marginal distribution to use may be fitted to thehistorical returns of the selected market factor during the selectedtime period bucket at 477. For example, the determined marginaldistribution to use may be a Gaussian distribution. Accordingly, μ and aof the Gaussian distribution may be determined. In one implementation,the Gaussian distribution may be fitted by calculating μ and a of thehistorical returns (e.g., of the calculated changes) of the selectedmarket factor during the selected time bucket. In one embodiment, thefitting may be implemented using Apache Spark. In some implementations,the fitting for multiple time buckets may occur in parallel. Forexample, a mapper function that performs the fitting and simulation foreach time bucket and utilizes group by on time buckets may beimplemented as follows:

reducer_simulator = generate_reducer_func(sim_id, 1 + num_sim_row /num_buckets) us_tsy_sim = us_tsy.map(lambda x: (x[0],x[2])).groupByKey(num_buckets).flatMap(reducer_simulator)

A copula for the processed market factors for the selected time periodbucket may be determined at 481. For example, the copula may be utilizedto capture the dependency structure between marginal distributions ofthe market factors during the selected time period bucket. In oneimplementation, the copula may be fitted as follows:

-   -   1. Feed factor return through its own CDF function to a        distribution of the grades; a uniformly distributed random        variable    -   2. Copula of a set of factors will be the joint distribution of        factors' grades. Joint=Copula+Marginals        For example, the SN R package may be utilized to determine the        copula and supports Gaussian, skewed Gaussian, T and Skewed T        Copula.

A multi-variate mixture model for the selected time period bucket may betrained at 485. For example, the multi-variate mixture model may be amulti-variate Gaussian mixture model. In one implementation, in Python,scipy.stats.multivariate_normal may be used for the different timeperiod buckets to formulate a multi-variate Gaussian mixture. In anotherimplementation, the SN R package may be utilized. In anotherimplementation, training of the Gaussian mixture models may beimplemented using Apache Spark. For example, the multi-variate mixturemodel for the selected time period bucket may be trained using theorg.apache.spark.ml.clustering.GaussianMixture.fit( ) function, and themulti-variate mixture model may take the form of aorg.apache.spark.ml.clustering.GaussianMixture multi-variate mixturedatastructure. In one embodiment, the marginal distribution may befitted to optimize the distributional families and their respectivedistributional parameters to minimize the KS test value between themarginal distribution and the historical distribution. In selectingvarious probability density functions such as Gaussian, skewed Gaussian,student T or skewed T copula, Cramer test and KS test values may beapplied to minimize the multivariate and/or marginal distributionsbetween simulated and historical data.

The number of market scenarios to simulate may be determined at 489. Forexample, 1,000 scenarios may be simulated (e.g., resulting in 60,000total simulated scenarios over 60 time period buckets). In oneimplementation, the machine learning simulated scenario processingrequest may be parsed (e.g., using PHP commands) to determine the numberof market scenarios to simulate for each of the time period buckets(e.g., based on the value of the number_of_simulated_market_scenariosfield). In another implementation, the number of market scenarios tosimulate for each of the time period buckets may be specified in aconfiguration setting. In another implementation, the number of marketscenarios to simulate may differ for different time period buckets.

A determination may be made at 493 whether there remain market scenariosto simulate. If so, a set of simulated market factor changes may begenerated using the multi-variate mixture model at 495. In oneimplementation, in Python, scipy.stats.multivariate_normal may be usedto generate the set of simulated market factor changes. In anotherimplementation, the SN R package may be utilized. In an alternativeimplementation, the set of simulated market factor changes may begenerated using the scikit-learnsklearn.mixture.BayesianGaussianMixture.sample( ) method.

The simulated scenario may be stored in a database at 499. In oneimplementation, the simulated scenario may be stored (e.g., in a batchwith other simulated scenarios) via a scenario results store request.

FIG. 5 shows a logic flow illustrating embodiments of a decision treeensembles training (DTET) component for the MLPO. In FIG. 5, a decisiontree ensembles training request may be obtained at 501. For example, thedecision tree ensembles training request may be obtained as a result ofan administrative user requesting training of decision tree ensembles.

Requested predictive capabilities may be determined at 505. For example,predictive capabilities may include estimating conditional Beta for asecurity, estimating conditional default for a security, and/or thelike. In one implementation, the decision tree ensembles trainingrequest may be parsed (e.g., using PHP commands) to determine therequested predictive capabilities (e.g., based on the value of thepredictive_capability_type fields). In another implementation, therequested predictive capabilities may be specified in a configurationsetting.

A universe of securities to process may be determined at 509. Forexample, the universe of securities (e.g., securities in the S&P 500Index) may include a list of equities, fixed income, and/or the likesecurities. In one implementation, the decision tree ensembles trainingrequest may be parsed (e.g., using PHP commands) to determine theuniverse of securities (e.g., based on the value of theuniverse_of_securities field). In another implementation, the universeof securities may be specified in a configuration setting.

A determination may be made at 513 whether there remain securities toprocess. In one implementation, each of the securities in the universeof securities may be processed. If there remain securities to process,the next security may be selected for processing at 517.

A determination may be made at 521 whether there remain predictivecapabilities to train for the selected security. In one implementation,each of the requested predictive capabilities for the selected securitymay be trained. If there remain predictive capabilities to train, thenext predictive capability may be selected for training at 525.

Features to use for training decision tree ensembles that provide theselected predictive capability for the selected security may bedetermined at 529. For example, different features may be used whentraining decision tree ensembles for fixed income and equity securities,for conditional Beta and conditional default. See FIGS. 6A-D forexamples of features that may be used when training decision treeensembles. In one implementation, the decision tree ensembles trainingrequest may be parsed (e.g., using PHP commands) to determine thefeatures to use for training (e.g., based on the value of thetraining_features field). In another implementation, the features to usefor training may be specified in a configuration setting.

A determination may be made at 533 whether sufficient training data isavailable for training decision tree ensembles that provide the selectedpredictive capability for the selected security. For example, if thefeatures to use for training include pricing history features, adetermination may be made if sufficient pricing history data for theselected security is available.

If sufficient training data is available for training decision treeensembles that provide the selected predictive capability for theselected security, the training data may be obtained at 537. In oneimplementation, a reference to a training data datastructure may beobtained. For example, the training data datastructure may be structuredas follows:

Target Feature_1_ID:Value Feature_2_ID:Value Feature_N_ID:Value (Beta)(cashmta) (ni_ta) (sec45) Data Point 1 1.1 1:0.3 2:0.5 4:1 Data Point 21.4 1:0.2 2:0.6 4:0As an example of training data for a muni instrument for estimatingBeta, the Beta of the instrument returns vs. muni index average returnover a three month time period may be calculated using rolling 3 monthdaily returns. This set of Beta is the target variable. The marketscenarios leading up to the return period are the trailing marketscenario features. Instrument to index relative features are used tocapture idiosyncratic risk (e.g., some muni instruments spread willtrade richer, others cheaper relative to the muni index average spread).The market scenarios within the return period are also used as features.

A determination may be made at 541 whether a termination condition fortraining decision tree ensembles that provide the selected predictivecapability for the selected security has been reached. In variousimplementations, the termination condition may comprise one or more of aspecified number of training iterations, a specified training time, aspecified minimum performance rank, and/or the like. For example, aperformance rank may be determined by calculating R² for the decisiontree ensembles (e.g., available data points may be split into 75%training data points and 25% testing data points for validation).

If the termination condition for training the decision tree ensembleshas not been reached, a determination may be made at 545 whether thereremain more training data points to use for training the decision treeensembles. In one implementation, each of the training data points inthe training data datastructure may be used for training. If thereremain more training data points, the next training data point (e.g.,Beta and feature values) may be selected at 549. The decision treeensembles may be trained on the selected training data point usinggradient boosting at 553. In one implementation, the XGBoost library maybe used to train the decision tree ensembles using the training datadatastructure. For example, in Python, using the XGBoost package, thedecision tree ensembles may be trained as follows:

Training: def exe_xgb(ft_pd): data = ft_pd.copy( ) X = data.iloc[:, 1:]y = data.iloc[:, 0] X_train, X_test, y_train, y_test =train_test_split(X, y, test_size=0.25) model = xgb.XGBRegressor( )model.fit(X_train, y_train) score = model.score(X test, y test) returnmodel, score Scoring: def calculate_inst(x): key_cusip  = x[0] ft_no_sim = x[1] model_cusip  = x[2] Row_list =[ ] features_pd  =ft_sim_pd_orig.copy( ) scoring_df  =features_pd[features_pd.columns[:ft_sim_ini]] ft_row_num =len(features_pd) ft_left = ft_no_sim.values * ft_row_num ft_left =pd.DataFrame(ft_left, columns=list(ft_no_sim.columns)) ft_right =features_pd[features_pd.columns[ft_sim_ini:]] X_scoring =pd.concat([ft_left, ft_right], axis=1) y_scoring  =model_cusip.predict(X_scoring) y_scoring  = pd.DataFrame(y_scoring,columns=[‘measure_value’]) y_scoring[‘asset_id’] = key_cusipy_scoring_complete = scoring_df.join(y_scoring) y_scoring_complete =y_scoring_complete[col_order] for index, rows iny_scoring_complete.iterrows( ): my_list =[int(rows.asset_id),int(rows.market_id), float(rows.measure_value)] Row_list.append(my_list)return Row_list

If the termination condition for training the decision tree ensembleshas been reached, the trained decision tree ensembles that provide theselected predictive capability for the selected security may be storedin a database at 557. In one implementation, the decision tree ensemblesmay be stored via a decision tree ensembles store request.

FIGS. 6A-D show implementation case(s) for the MLPO. In FIGS. 6A-D,features that may be used for estimating conditional Beta and/orconditional default are illustrated.

FIG. 7A shows a logic flow illustrating embodiments of an expectedreturns calculation (ERC) component for the MLPO. In FIG. 7A, anexpected returns calculation request may be obtained at 701. Forexample, the expected returns calculation request may be obtained as aresult of an administrative user requesting calculation of expectedreturns for a universe of securities under simulated scenarios (e.g., ofa simulation).

The universe of securities to process may be determined at 705. Forexample, the universe of securities (e.g., securities in the S&P 500Index) may include a list of equities, fixed income, and/or the likesecurities. In one implementation, the expected returns calculationrequest may be parsed (e.g., using PHP commands) to determine theuniverse of securities (e.g., based on the value of theuniverse_of_securities field). In another implementation, the universeof securities may be specified in a configuration setting.

A determination may be made at 709 whether there remain securities toprocess. In one implementation, each of the securities in the universeof securities may be processed. If there remain securities to process,the next security may be selected for processing at 713.

Simulated market scenarios to analyze may be determined at 715. In oneimplementation, the expected returns calculation request may be parsed(e.g., using PHP commands) to determine the simulated market scenariosto analyze (e.g., based on the values of the simulation_identifier fieldand/or the simulated_scenarios field). In another implementation, thesimulated market scenarios to analyze may be specified in aconfiguration setting.

A determination may be made at 717 whether there remain simulated marketscenarios to analyze. In one implementation, each of the simulatedmarket scenarios (e.g., of the simulation) may be analyzed. If thereremain simulated market scenarios to analyze, the next market scenario(e.g., from the 60,000 simulated scenarios) may be selected for analysisat 721.

Features to utilize for conditional Beta estimation for the selectedsecurity under the selected simulated market scenario may be determinedat 725. For example, different features may be used when estimatingconditional Beta for fixed income and equity securities. In oneimplementation, the features that were used for training decision treeensembles for estimating conditional Beta, as discussed with regard toFIG. 5, may be utilized. In one embodiment, the calculation ofconditional Beta for different assets may be parallelized using ApacheSpark. The mapper function may partition by asset_id, such as CUSIP, andmay use XGBoost to train a model for each asset. The data frames for theXGBoost models may be stored as binary data as part of the calculationworkflow to a relational database concurrently. The scoring process thatgenerates a distribution of Beta for each asset may also beparallelized. The data storage design and parallel computingimplementation of the MLPO allows each asset to have its own set ofresiduals. The residuals may be further analyzed to ensure that there isno systematic bias overstating or understating the simulated Beta,and/or that the residuals are not correlated with the simulated Beta.The sum of the simulated Beta from common risk factors and the residualsmay be stored as the final simulated Beta. For example, the XGBoostmodel may be executed as follows:

model_function = generate_model(model_column, instrument_column,ratio_column, factor_column, delta_length, time_series_length,delta_name, feature_engineering_function_name, xgb_function_name)conditional_beta_model = raw_data.rdd \ .map(extract cusip)\.groupByKey(num_partitions)\.map(function_including_feature_engineering_and_xgb)

A determination may be made at 729 whether sufficient estimation data isavailable for estimating conditional Beta for the selected securityunder the selected simulated market scenario. In one implementation, adetermination may be made whether instrument data for the selectedsecurity during the time period associated with the selected simulatedmarket scenario is available. For example, if the features to use forconditional Beta estimation include pricing history features, adetermination may be made if pricing history data for the selectedsecurity is available during the time period associated with theselected simulated market scenario. In another implementation, adetermination may be made whether decision tree ensembles for estimatingconditional Beta for the selected security exist. For example, ifsufficient training data was not available, decision tree ensembles forestimating conditional Beta for the selected security may not have beentrained.

If sufficient estimation data is available (e.g., decision treeensembles exist and pricing history data is available), the selectedsecurity's conditional Beta may be estimated using the decision treeensembles trained to estimate conditional Beta for the selected securityat 733. In one implementation, the decision tree ensembles may bequeried to predict the selected security's conditional Beta based on theestimation data.

If sufficient estimation data is not available (e.g., decision treeensembles do not exist or pricing history data is not available), theselected security's conditional Beta may be estimated using a machinelearning (ML) method at 737. In one implementation, the k-NN method maybe used to estimate conditional Beta for the selected security byfinding the closest modeled security to the selected security, and usingthe closest modeled security's estimated conditional Beta as a proxy ofthe selected security's estimated conditional Beta. For example, thefeatures to utilize for conditional Beta estimation may be used asinputs to the k-NN to find the closest modeled security.

Features to utilize for conditional default probability estimation forthe selected security under the selected simulated market scenario maybe determined at 741. For example, different features may be used whenestimating conditional default probability for fixed income and equitysecurities. In one implementation, the features that were used fortraining decision tree ensembles for estimating conditional defaultprobability, as discussed with regard to FIG. 5, may be utilized.

A determination may be made at 745 whether sufficient estimation data isavailable for estimating conditional default probability for theselected security under the selected simulated market scenario. In oneimplementation, a determination may be made whether instrument data forthe selected security during the time period associated with theselected simulated market scenario is available. For example, if thefeatures to use for conditional default probability estimation includepricing history features, a determination may be made if pricing historydata for the selected security is available during the time periodassociated with the selected simulated market scenario. In anotherimplementation, a determination may be made whether decision treeensembles for estimating conditional default probability for theselected security exist. For example, if sufficient training data wasnot available, decision tree ensembles for estimating conditionaldefault probability for the selected security may not have been trained.In one embodiment, the calculation of default probability for differentassets may be parallelized using Apache Spark. The mapper function maypartition by asset_id, such as CUSIP, and may use XGBoost to train amodel for each asset. Features, such as company financials data andmacro factors, may be distributed by asset id. The data frames for theXGBoost models may be stored as binary data as part of the calculationworkflow to a relational database concurrently. The scoring process thatgenerates a default probability distribution for each asset undervarious simulated market scenarios may also be parallelized with factorsimulation data broadcasted to the worker nodes. The data storage designand parallel computing implementation of the MLPO allows each instrumentto have its own XGBoost model. For example, the XGBoost model may beexecuted as follows:

model_function = generate_model(model_column, instrument_column,ratio_column, factor_column, delta_length, time_series_length,delta_name, feature_engineering_function_name, xgb_function_name,sector_column, default_probability_column) conditional_default_model =raw_data.rdd \ .map(extract cusip)\ .groupByKey(num_partitions)\.map(function_including_feature_engineering_and_xgb)

If sufficient estimation data is available (e.g., decision treeensembles exist and pricing history data is available), the selectedsecurity's conditional default probability may be estimated using thedecision tree ensembles trained to estimate conditional defaultprobability for the selected security at 749. In one implementation, thedecision tree ensembles may be queried to predict the selectedsecurity's conditional default probability based on the estimation data.

If sufficient estimation data is not available (e.g., decision treeensembles do not exist or pricing history data is not available), theselected security's conditional default probability may be estimatedusing a machine learning (ML) method at 753. In one implementation, thek-NN method may be used to estimate conditional default probability forthe selected security by finding the closest modeled security to theselected security, and using the closest modeled security's estimatedconditional default probability as a proxy of the selected security'sestimated conditional default probability. For example, the features toutilize for conditional default probability estimation may be used asinputs to the k-NN to find the closest modeled security.

Default for the selected security under the selected simulated marketscenario may be simulated at 757. In one implementation, the value of arandom variable that has values corresponding to Default (e.g., withprobability equal to: the selected security's conditional defaultprobability) and No Default (e.g., with probability equal to: 1—theselected security's conditional default probability) expected returntypes may be simulated. For example, the value of the random variablemay be randomly generated from a standard normal distribution as anumber from 0 to 1. If the number is smaller than the estimatedconditional default probability, the default value is set to 1(Default), otherwise to 0 (No Default) (e.g., if the conditional defaultprobability for market scenario 10001 is 10% and the randomly generatednumber is 0.312, then the asset's default flag for scenario 10001 is setto 0 (No Default); if the randomly generated number is 0.05, which issmaller than 0.1 (10% default probability), then the asset's defaultflag for scenario 10001 is set to 1 (Default)).

A determination may be made at 761 whether the expected return type forthe selected security under the selected simulated market scenario isDefault or No Default. If the expected return type is No Default, anexpected return for the selected security under the selected simulatedmarket scenario may be calculated at 765. For example, the expectedreturn (ER) may be calculated as follows:

Fixed Income Assets—No Default:

${ER} = {{\sum\limits_{{factor} = 1}^{n}{{{Exposure}\left( {f,i} \right)} \times {Conditional}\mspace{14mu}{{Beta}\left( {i,m} \right)} \times {Simulated}\mspace{14mu}{Factor}\mspace{14mu}{{Change}\left( {f,m} \right)}}} + {Carry} + {Rolldown}}$

Equity Assets—No Default:

ER=Conditional Beta(i,m)×Simulated Return of Equity Index(f,m)

-   -   Where:    -   f is the number of market factors for which an instrument has        price sensitivities    -   i is the number of instruments in the investable universe    -   Exposure is a f by i matrix that contains instruments' return        sensitivities to market factors. They are calculated as the Beta        of instruments' return to the market factor change. For example,        for fixed income instruments, the exposure to interest rate risk        factors may be option adjusted durations. They may be calculated        by moving the rates up and down “shocking the yield curve”,        discounting the cashflows of the bond while adjusting for        optionality. The bigger the differences in present values for a        given unit of interest rate shock, the higher the duration, aka        “return sensitivity to rates”.    -   m is the number of simulated market scenarios    -   For example, each instrument i may have a different Beta along        each simulated market scenario    -   Conditional Beta is a i by m matrix    -   Simulated Factor Change is a f by m matrix; each market factor        may have a simulated change value along each market scenario    -   Equity Index is a market factor simulated along with other        market factors    -   Conditional beta may be calculated for individual equities        against their respective equity indices for each simulated        market scenario.

If the expected return type is Default, an expected return for theselected security under the selected simulated market scenario may becalculated at 769. For example, the expected return (ER) may becalculated as follows:

Fixed Income Assets—Default:

${ER} = \frac{\left( {\left( {{Recovery}\mspace{14mu}{Rate} \times 100} \right) - {Price}} \right)}{Price}$

Equity Assets—Default:

ER=0

-   -   Where:

${{Recovery}\mspace{14mu}{Rate}} = {1 - \frac{{Credit}\mspace{14mu}{Spread}}{{Conditional}\mspace{14mu}{Default}\mspace{14mu}{Probability}}}$

The calculated expected returns may be stored in a database at 773. Inone implementation, the calculated expected returns may be stored via anexpected returns store request.

FIG. 7B illustrates embodiments of a computation engine architecturethat supports and implements the business logic. In variousimplementations the computation engine may be characterized by thefollowing features:

1: Parallel on Parallel Hierarchy and Flexible Calculation Dependencies:Use Apache AirFlow to define calculation workflow and enable concurrentprocessing of a single or multiple calculation module(s) and flexibledependencies. For example, 3 month, 6 month and 12 months (e.g., basedon rolling window period length) simulations from multiple factorsimulation models may be processed in parallel. The dependencymanagement allows risk data maintenance and pushing risk analytics to acloud based datamart (e.g., SnowFlake) upon the completion of assetreturn simulation for assets across time horizons and simulation models.Furthermore, within each calculation module, Apache Spark may be used toenable parallel computing of instruments. For example, to calculate 12month asset return simulation for the deep learning model (asim1Y_DL_CMA), over 130,000 bond instruments may be distributed acrosshundreds of worker nodes in the cloud. This type of parallel on top ofparallel technology approach maximizes the utilization of cloud basedcomputing power and provides control and flexibility for definingcalculation dependencies.

2: Self-Service: Computation capabilities may be authored by domainexperts. Team members may orchestrate and assemble the capabilities anddeclare dependencies with custom built WDL (Workflow DeclarationLanguage). In one implementation, YAML may be used as the WDL.

3: Heterogenous Platforms: Various computation platforms such asparallel computing using Apache Spark using Scala/Java/Python,distributed computing on Virtual Servers using Golang, SQL and shellscripts, and/or the like may be supported.

4: Event-Based: Tasks in the Workflow may be automatically triggeredbased on events.

5: Cloud provider Agnostic: Open source technologies such as ApacheAirflow, Apache Spark and Postgresq1, and/or the like may be leveraged.

6: Performance Optimization: Computation performance may be optimized byusing network-optimized, memory-optimized and/or compute-optimized cloudinstances based on the nature of the computation. Multiple jobs may bescheduled to single or multiple clusters.

7: Cost Optimization: Inexpensive commodity-grade virtual servers may beprovisioned dynamically leveraging inexpensive Spot Instances orReserved Instances.

An exemplary WDL that orchestrates the workflow and the dependencies maybe implemented as follows:

default: owner: ‘atim-de’ dag: dag_id: atim-pg-prod tasks:create_cluster: operator: PythonOperator python_callable: create_emrop_kwargs: {‘num_core_nodes’: 28} wait_for_cluster_completion: operator:PythonOperator python_callable: wait_for_completion terminate_cluster:operator: PythonOperator python_callable: terminate_emr bond_am:operator: PythonOperator python_callable: run_spark_job op_kwargs:{‘file’: ‘s3://codebase/bond_am.jar’, ‘conf’:‘s3://codebase/bond_am/app.conf’, ‘className’:‘com.atim.data.ETLHashDirect’} fund_am: operator: PythonOperatorpython_callable: run_spark_job op_kwargs: {‘file’:‘s3://codebase/fund_am.jar’, ‘conf’: ‘s3://codebase/fund_am/app.conf’,‘className’: ‘com.atim.data.ETLHashDirect’} bond_expo: operator:PythonOperator python_callable: run_spark_job op_kwargs: {‘file’:‘s3://codebase/bond_expo.jar’, ‘conf’:‘s3://codebase/bond_expo/app.conf’, ‘className’:‘com.atim.data.ETLHashDirect’} fund_expo: operator: PythonOperatorpython_callable: run_spark_job op_kwargs: {‘file’:‘s3://codebase/fund_expo.jar’, ‘conf’:‘s3://codebase/fund_expo/app.conf’, ‘className’:‘com.atim.data.ETLHashDirect’} merge_am: operator: PythonOperatorpython_callable: run_spark_job op_kwargs: {‘file’:‘s3://codebase/merge_am.jar’, ‘conf’: ‘s3://codebase/merge_am/app.conf’,‘className’: ‘com.atim.data.S3MergeMapAm’} merge_expo: operator:PythonOperator python_callable: run_spark_job op_kwargs: {‘file’:‘s3://codebase/merge_expo.jar’, ‘conf’:‘s3://codebase/merge_expo/app.conf’, ‘className’:‘com.atim.data.S3MergeMap’} asim3M_DL_CMA: operator: PythonOperatorpython_callable: run_spark_job op_kwargs: {‘file’:‘s3://codebase/postgres/main.py’, ‘pyFiles’:[“s3://codebase/postgres/asim.zip”], ‘args’:[‘atimProdConfig_DL_3M.yml’]} asim6M_DL_CMA: operator: PythonOperatorpython_callable: run_spark_job op_kwargs: {‘file’:‘s3://codebase/postgres/main.py’, ‘pyFiles’:[“s3://codebase/postgres/asim.zip”], ‘args’:[‘atimProdConfig_DL_6M.yml’]} asim1Y_DL_CMA: operator: PythonOperatorpython_callable: run_spark_job op_kwargs: {‘file’:‘s3://codebase/postgres/main.py’, ‘pyFiles’:[“s3://codebase/postgres/asim.zip”], ‘args’:[‘atimProdConfig_DL_1Y.yml’]} asim1Y_DL_NONCMA: operator: PythonOperatorpython_callable: run_spark_job op_kwargs: {‘file’:‘s3://codebase/postgres/main.py’, ‘pyFiles’:[“s3://codebase/postgres/asim.zip”], ‘args’:[‘atimProdConfig_DL_1Y_NonCMA.yml’]} asim3M_MV_CMA: operator:PythonOperator python_callable: run_spark_job op_kwargs: {‘file’:‘s3://codebase/postgres/main.py’, ‘pyFiles’:[“s3://codebase/postgres/asim.zip”], ‘args’:[‘atimProdConfig_MV_3M.yml’]} asim6M_MV_CMA: operator: PythonOperatorpython_callable: run_spark_job op_kwargs: {‘file’:‘s3://codebase/postgres/main.py’, ‘pyFiles’:[“s3://codebase/postgres/asim.zip”], ‘args’:[‘atimProdConfig_MV_6M.yml’]} asim1Y_MV_CMA: operator: PythonOperatorpython_callable: run_spark_job op_kwargs: {‘file’:‘s3://codebase/postgres/main.py’, ‘pyFiles’:[“s3://codebase/postgres/asim.zip”], ‘args’:[‘atimProdConfig_MV_1Y.yml’]} db_data_maintenance: operator:BashOperator bash_command: ‘query’ push_asset_to_snowflake: operator:BashOperator bash_command: “snowflake_asset.sh’”push_assetsim_to_snowflake: operator: BashOperator bash_command:“snowflake_assetsim.sh” dependancies: - create_cluster >>wait_for_cluster_completion - wait_for_cluster_completion >> bond_expo -bond_expo >> fund_expo, bond_am, fund_am - bond_am, fund_am >>merge_am - bond_expo, fund_expo >> merge_expo - merge_am >> merge_expo -merge_expo >> asim3M_DL_CMA, asim6M_DL_CMA, asim1Y_DL_CMA,asim1Y_DL_NONCMA, asim3M_MV_CMA, asim6M_MV_CMA, asim1Y_MV_CMA -asim3M_DL_CMA, asim6M_DL_CMA, asim1Y_DL_CMA, asim1Y_DL_NONCMA,asim3M_MV_CMA, asim6M_MV_CMA, asim1Y_MV_CMA >> terminate_cluster -terminate_cluster >> db_data_maintenance - terminate_cluster >>push_asset_to_snowflake - push_asset_to_snowflake >>push_assetsim_to_snowflake

The visual view of the above workflow is illustrated at 702 in FIG. 7C.

Exemplary pseudo code that distributes the asset simulation acrossprovisioned clusters of nodes is shown below. Exposure data in ‘expo’and factor simulation data (encapsulated in the curried functionfsim_func) may be broadcasted to the worker nodes for distributedcomputation.

Expo data are read and partitioned by asset_id: expo_tall_sdf =self.sqlContext.read.jdbc( url=self.jdbc_conn_str, table=fexpo_sql,properties=conn_props ) partition_meta = { ‘numPartitions’:str(self.read_partitions), ‘partitioncolumn’: ‘ asset_id’, ‘lowerBound’:‘0’, ‘upperBound’: str(self.select_fexpo_count(pricing_dt)) }expo.rdd.map(fsim_func)

Calculations may be executed concurrently on the worker nodes usingpseudo code such as shown below. Factor Sims may be broadcasted to theworker nodes.

def calculate_inst(x): “““ Performs dot product between row of FactorExposer RDD (x) and Factor Sim matrix return as list of lists. ””” sy =asset_ref_dict.get(str(x.asset_id), { }).get(“static_yield”,Decimal(‘0.0’)) # month to mature mon2mature =asset_ref_dict.get(str(x.asset_id), { }).get(“month_to_mature”, { })bias_coef = bias_coef_with_month2mature(mon2mature, horizon) # Dotproduct and set datatype as float fsim = fsim_vals.astype(float) fexpo =np.array(x)[fexpo_fctr_idx].astype(float) return_arry = fsim.dot(fexpo)# clip return via option price upper and lower p_lower =asset_ref_dict.get(str(x.asset_id), { }).get(“price_lower”, { }) p_upper= asset_ref_dict.get(str(x.asset_id), { }).get(“price_upper”, { })return_clip = clip_lower_and_upper(p_lower, p_upper, return_arry) # addcarry return_clip_plus_carry = np.array(return_clip).astype(float) +float(bias_coef) * float(sy) # CVaR calculation cvar_minus =np.mean(np.sort(return_clip_plus_carry)[:int(len(return_clip_plus_carry) *cvar_percentile * 0.01)]) return_int = array2int(return_clip_plus_carry)return [x.asset_id, x.pricing_dt, sim_id, return_int, float(cvar_minus)]

The generated asset simulation data may be populated into RDMSPostgresq1 and Enterprise Snowflake Data Lake in a wide format foroptimal performance. The wide format is illustrated at 706 in FIG. 7C.

The wide format may be turned into a tall format for reporting andanalysis as follows:

SELECT asset_id, sim_id, generate_series(0,7449) market_id,unnest(returns) as returns FROM prod.asset_sim_w WHEREasset_id=2012082100000122 and sim_id=34 and pricing_dt=‘2020-06-05’ORDER BY 1,2,3;

The tall format is illustrated at 710 in FIG. 7C. In this figure, marketscenario identifier field scenario_identifier is referred to asmarket_id.

FIG. 8 shows a datagraph illustrating data flow(s) for the MLPO. In FIG.8, a user client 804 (e.g., of a user) may send a portfolio constructionrequest 821 to a MLPO server 806 to facilitate creating an optimizedportfolio. For example, the user client may be a desktop, a laptop, atablet, a smartphone, a smartwatch, and/or the like that is executing aclient application. In one implementation, the portfolio constructionrequest may include data such as a request identifier, optimizationparameters (e.g., investable universe, time period, total investmentamount, conditional value at risk (CVaR) percentile, CVaR threshold,whether to optimize relative to a benchmark portfolio, benchmarkportfolio weights, integer quantity constraint, number of positionsthreshold (e.g., lower bound), position market value weight threshold(e.g., upper bound), etc.), and/or the like. In one embodiment, the userclient may provide the following example portfolio construction request,substantially in the form of a HTTP(S) POST message includingXML-formatted data, as provided below:

POST /portfolio_construction_request.php HTTP/1.1 Host: www.server.comContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <portfolio_construction_request><request_identifier>ID_request_11</request_identifier><optimization_parameters> <investable_universe>Securities in S&P500</investable_universe> <time_period>6 months</time_period><total_amount>$1,000,000</total_amount><CVAR_percentile>5%</CVAR_percentile><CVAR_threshold>10%</CVAR_threshold><is_relative_to_benchmark_portfolio>FALSE</is_relative_to_benchmark_portfolio><integer_quantity_constraint>TRUE</integer_quantity_constraint><number_of_positions_threshold>at least30</number_of_positions_threshold><position_weight_threshold>10%</position_weight_threshold></optimization_parameters> </portfolio_construction_request>

The MLPO server 806 may send an expected returns retrieve request 825 toa repository 810 to facilitate retrieving expected returns forsecurities in the portfolio universe for simulated scenarios (e.g.,filtered) corresponding to the specified time period. In oneimplementation, the expected returns retrieve request may include datasuch as a request identifier, expected returns to retrievespecification, and/or the like. In one embodiment, the MLPO server mayprovide the following example expected returns retrieve request,substantially in the form of a HTTP(S) POST message includingXML-formatted data, as provided below:

POST /expected_returns_retrieve_request.php HTTP/1.1 Host:www.server.com Content-Type: Application/XML Content-Length: 667 <?XMLversion = “1.0” encoding = “UTF-8”?> <expected_returns_retrieve_request><request_identifier>ID_request_12</request_identifier><expected_returns_specification><simulation_identifier>ID_sim_1</simulation_identifier> <scenario><scenario_identifier>ID_scenario_1</scenario_identifier><securities>MSFT, AAPL, ...</securities> </scenario> <scenario><scenario_identifier>ID_scenario_2</scenario_identifier><securities>MSFT, AAPL, ...</securities> </scenario> ...</expected_returns_specification> </expected_returns_retrieve_request>

The repository 810 may send an expected returns retrieve response 829 tothe MLPO server 806 with the requested expected returns data. In oneimplementation, the expected returns retrieve response may include datasuch as a response identifier, the requested expected returns data,and/or the like. In one embodiment, the repository may provide thefollowing example expected returns retrieve response, substantially inthe form of a HTTP(S) POST message including XML-formatted data, asprovided below:

POST /expected_returns_retrieve_response.php HTTP/1.1 Host:www.server.com Content-Type: Application/XML Content-Length: 667 <?XMLversion = “1.0” encoding = “UTF-8”?><expected_returns_retrieve_response><response_identifier>ID_response_12</response_identifier><expected_returns> <scenario><scenario_identifier>ID_scenario_1</scenario_identifier> <security><security_identifier>MSFT</security_identifier><expected_return>10%</expected_return> </security> <security><security_identifier>AAPL</security_identifier><expected_return>12%</expected_return> </security> ... </scenario><scenario> <scenario_identifier>ID_scenario_2</scenario_identifier><security> <security_identifier>MSFT</security_identifier><expected_return>15%</expected_return> </security> <security><security_identifier>AAPL</security_identifier><expected_return>13%</expected_return> </security> ... </scenario> ...</expected_returns> </expected_returns_retrieve_response>

A portfolio constructing (PC) component 833 may utilize data provided inthe portfolio construction request and/or the expected returns retrieveresponse and/or via filters to determine and/or execute a set oftradeable buy and/or sell transactions to construct an optimizedportfolio. See FIG. 9 for additional details regarding the PC component.

The MLPO server 806 may send an order execution request 837 to anexchange server 808 to facilitate executing a tradeable buy and/or selltransaction used to construct the optimized portfolio. In oneimplementation, the order execution request may include data such as arequest identifier, order details, and/or the like. In one embodiment,the MLPO server may provide the following example order executionrequest, substantially in the form of a HTTP(S) POST message includingXML-formatted data, as provided below:

POST /order_execution_request.php HTTP/1.1 Host: www.server.comContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <order_execution_request><request_identifier>ID_request_13</request_identifier> <order_details><security_identifier>AAPL</security_identifier> <action>BUY</action><quantity>1000 shares</quantity> </order_details></order_execution_request>

The exchange server 808 may send an order execution response 841 to theMLPO server 806 to confirm that the tradeable buy and/or selltransaction was executed successfully. In one implementation, the orderexecution response may include data such as a response identifier, astatus, and/or the like. In one embodiment, the exchange server mayprovide the following example order execution response, substantially inthe form of a HTTP(S) POST message including XML-formatted data, asprovided below:

POST /order_execution_response.php HTTP/1.1 Host: www.server.comContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <order_execution_response><response_identifier>ID_response_13</response_identifier><status>OK</status> </order_execution_response>

The MLPO server 806 may send a portfolio construction response 845 tothe user client 804 to inform the user that an optimized portfolio wasconstructed successfully. In one implementation, the portfolioconstruction response may include data such as a response identifier, astatus, and/or the like. In one embodiment, the MLPO server may providethe following example portfolio construction response, substantially inthe form of a HTTP(S) POST message including XML-formatted data, asprovided below:

POST /portfolio_construction_response.php HTTP/1.1 Host: www.server.comContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <portfolio_construction_response><response_identifier>ID_response_11</response_identifier><status>OK</status> </portfolio_construction_response>

FIG. 9 shows a logic flow illustrating embodiments of a portfolioconstructing (PC) component for the MLPO. In FIG. 9, a portfolioconstruction request may be obtained at 901. For example, the portfolioconstruction request may be obtained as a result of a user requestingcreation of an optimized portfolio.

Optimization parameters for constructing the optimized portfolio may bedetermined at 905. For example, the optimization parameters may includea universe of investment securities, investment amount, ConditionalValue at Risk (CVaR) percentile, CVaR threshold, an investment timeperiod, whether to optimize relative to a benchmark portfolio, benchmarkportfolio weights, integer quantity constraint, and/or the like. In oneimplementation, the portfolio construction request may be parsed (e.g.,using PHP commands) to determine the optimization parameters (e.g.,based on the value of the optimization_parameters field). For example,the optimization parameters may be specified as follows:

Arguments

-   -   1. market_value=1e7        -   Total amount of cash (e.g., in US dollars) provided for            investment. Default 1e7. Note that (the holding portfolio            market value)+(cash residue)=total_dollar_amount.    -   2. cvar_percentile=5        -   The percentage of worst outcome. Default 5.    -   3. cvar_threshold=−450        -   The expected loss at the cvar_percentile worst outcome.            Default −450.    -   4. investable_universe        -   A list of the assets that could be allocated.    -   5. asset_sim        -   A 2d list, each row is a simulated scenario, and each column            is an asset. The order of the columns should be the same as            the order in the investable_universe.    -   6. asset_return        -   A list of expected yields of the assets, with the same order            of the investable_universe.    -   7. asset_price        -   A list of price (e.g., in US dollar) of the assets with the            same order of the investable_universe.    -   8. asset_min_denom        -   A list of the minimum par-amount to purchase for each asset,            following the same order in the investable_universe.            Rescaled to quantity by dividing 100 inside the optimization            solver.    -   9. asset_min_incrmnt        -   A list of the par-amount increment to purchase for each            asset, following the same order in the investable_universe.            Rescaled to quantity by dividing 100 inside the optimization            solver.    -   Additional Optional Arguments    -   10. pct_univ_allocated=0.8 when number of assets <=10 else 0.6        -   The fraction of the allocated assets in all the assets.            Default 0.8 when number of assets <=10, else 0.6.    -   11. allocation_ub=0.8*market_value/asset_price        -   A 1d list of the upper bound of allocated quantity of each            asset with the same order of the investable_universe.            Default 0.8*market_value/asset_price.    -   12. allocation_1b=1e−3*market_value/asset_price        -   A 1d list of the lower bound of allocated quantity of the            allocated assets with the same order of the            investable_universe. Default 1e−3*market_value/asset_price.    -   13. available_2_trade=market_value/asset_price        -   A 1d list of the maximum available quantity of the assets            with the same order of the investable_universe. Default            market_value/asset_price.    -   14. is_allocate_neg_rtn=True        -   Boolean. If True, assign zero weights to assets with            negative expected return (in arg #6). Default True.    -   15. max_exe_time=120        -   The maximum execution time in seconds. If no allocation            solution found within the max_exe_time (e.g., default 2            mins), the optimization solver returns 0 for the assets.    -   16. is_relative=False        -   Boolean. If True and tracking_error (arg #17) is not None            and asset_quant_base (arg #18) is not None, relative            algorithm may be triggered. Default False.    -   17. bmk_weight=None        -   A 1d list of the allocation weights of the benchmark            portfolio. Default is None. Note that when arg #16 is True,            and arg #17 is not None, and arg #18 is not None, the            relative algorithm may be triggered.    -   18. bmksim=None        -   A 2d list of the simulation scenarios of the assets in the            benchmark portfolio. Each row is a scenario, and each column            is an asset. Rows follows the order of that in asset_sim(arg            #5), and columns follow the order of that in bmk_weight(arg            #17). Default None. Note that when arg #16 is True, and arg            #17 is not None, and arg #18 is not None, the relative            algorithm may be triggered.    -   19. convergence_threshold=1e−3        -   The minimum delta of the objective function in the            branch-and-cut searching algorithm.

Market scenarios to utilize for constructing the optimized portfolio maybe determined at 907. In one embodiment, the market scenarios to utilizemay be determined based on the simulation model (e.g., for a specifiedpricing date) and/or time period length selected by the user. Forexample, the user may choose to utilize simulated market scenariosgenerated using a deep learning neural network simulation model (e.g.,for the specified pricing date) for a 3 month, 6 month or 1 yearinvestment time period (e.g., as discussed with regard to FIGS. 2A-B),or to utilize simulated market scenarios generated using a multivariatemixture simulation model (e.g., for the specified pricing date) for a 3month, 6 month or 1 year investment time period (e.g., as discussed withregard to FIG. 4). In another embodiment, the market scenarios toutilize may be determined based on filters applied to simulated marketscenarios. For example, the user may choose to filter simulated marketscenarios based on specified ranges of allowable values for specifiedcustomized market factors (e.g., as discussed with regard to FIG. 21),and/or based on specified business cycle settings (e.g., as discussedwith regard to FIG. 27).

Expected returns of securities in the universe of investment securitiesfor the determined market scenarios to utilize may be retrieved from adatabase at 909. For example, if the user wishes to construct anoptimized portfolio for a 6 month investment time period using a deeplearning neural network simulation model, expected returns of securitiesin the universe of investment securities for simulated market scenariosgenerated by the deep learning neural network simulation model for 6month rolling window periods (e.g., for the 60,000 simulated scenarios)may be retrieved. In another example, if the user wishes to construct anoptimized portfolio conditional on VIX rising more than 400 bps over a 3month horizon, expected returns of securities in the universe ofinvestment securities for filtered simulated market scenarios having VIXchange greater than 400 bps over the 3 month horizon may be retrieved.In another example, if the user wishes to construct an optimizedportfolio conditional on having Late business cycle over a 3 monthhorizon, expected returns of securities in the universe of investmentsecurities for filtered simulated market scenarios associated with Latebusiness cycle over the 3 month horizon may be retrieved (e.g.,alternatively, weighted expected security returns may be utilized whenmultiple business cycles with associated business cycle weights areutilized). In one implementation, the expected returns may be retrievedvia an expected returns retrieve request.

A determination may be made at 913 whether the optimized portfolioshould be optimized relative to a benchmark portfolio. If so, startingsecurities weights may be initialized to benchmark portfolio weights at917.

Portfolio securities weights may be optimized in accordance with theoptimization parameters at 921. In one implementation, the PC componentmay perform a convex optimization to find a mixed integer linearprogramming (MILP) portfolio solution that ensures that tradable buy andsell transactions can be generated. The optimization objective may beset to maximize the expected portfolio return. In various embodiments, avariety of approaches may be used to perform the optimization. Forexample, one approach is to use stochastic optimization process tosearch for suboptimal weights of the asset for a fixed amount of timeand/or iterations and select the solution with allowable CVaR andmaximum returns. For example, a second approach is to use MILP to solvefor the global optimum solution and use linear relaxation of CVaRconstraint with the weights result in tradability for each securityrespecting the trading rules such as minimum denomination and minimumincrements. For example, a third approach is to use linear relaxation ofCVaR constraint, but use a binary branch and cut modified MILPimplementation (BILP), where non-integer solutions are allowed for thosebigger than the minimum denomination values. For example, a fourthapproach is to use linear relaxation of CVaR constrain and conduct adirect linear programing optimization, allowing the allocated weights tobe a non-integer (decimal) solution and rounding the trade quantity tothe nearable tradable amount. In one embodiment, the optimizationimplementation may be solver independent. In various implementations,multiple linear programming, quadratic programming and mixed integerprogramming solvers may be supported, including both commercial solversand open-source solvers (e.g., CVXOPT(SIMPLEX), GUROBI,scypy.optimize(interior point)). For example, the user may select whichsolvers to use from a portfolio construction graphical user interface.

Tradeable buy and/or sell transactions to execute may be determined at925. In one embodiment, the tradeable buy and/or sell transactions aregenerated to make weights of securities in the optimized portfoliocorrespond to the determined optimized portfolio securities weights. Inone implementation, the optimized portfolio may be a newly createdportfolio. For example, tradeable buy transactions may be determined toobtain each security with a non-zero weight in accordance with itsoptimized portfolio weight. In another implementation, the optimizedportfolio may be an existing portfolio (e.g., the benchmark portfolio).For example, tradeable buy and/or sell transactions may be determined toincrease and/or reduce weights of securities in the existing portfolioto make the weight of each security correspond to its optimizedportfolio weight.

The tradeable buy and/or sell transactions may be executed at 929. Inone implementation, orders corresponding the tradeable buy and/or selltransactions may be sent to an exchange server via one or more orderexecution requests.

FIG. 10 shows a screenshot illustrating user interface(s) of the MLPO.In FIG. 10, an exemplary user interface (e.g., for a mobile device, fora website) for constructing an optimized portfolio is illustrated.Screen 1001 shows that a user may utilize a securities universe widget1005 to specify a universe of investment securities. For example, theuser may specify a set of equities, bonds, indexes, portfolio holdings,and/or the like. The user may utilize a benchmark widget 1007 to specifya benchmark portfolio relative to which the optimized portfolio shouldbe optimized. The user may utilize a simulation model widget 1010 tospecify a simulation model that should be utilized. The user may utilizea pricing date widget 1015 to specify a pricing date associated with thesimulation model. The user may utilize a portfolio market value widget1020 to specify an investment amount.

FIG. 11 shows a screenshot illustrating user interface(s) of the MLPO.In FIG. 11, an exemplary user interface (e.g., for a mobile device, fora website) for constructing an optimized portfolio is illustrated.Screen 1101 shows that the user may utilize a CVaR percentile widget1105 to specify the percentile (e.g., 5%) of the worst return outcomes.The user may utilize a CVaR threshold widget 1110 to specify theexpected loss (e.g., 7%) at the worst CVaR percentile outcomes (e.g.,the expected loss based on a weighted average (e.g., weighted based onoccurrence probability) of the worst 5% of return outcomes). The usermay utilize an investment time period widget 1115 to specify theinvestment time frame (e.g., over a 3 month time period). The user mayutilize optimization objective widgets 1120, 1125 to specify theoptimization objective (e.g., maximize total return). Other portfolioconstruction constraints that may be specified by the user may include:maximum percentage market value (PMV) per allocated asset, minimumnumber of allocated assets per portfolio, and/or the like. The user mayutilize an optimize widget 1130 to initiate the creation of theoptimized portfolio.

FIG. 12 shows a screenshot illustrating user interface(s) of the MLPO.In FIG. 12, an exemplary user interface (e.g., for a mobile device, fora website) for constructing an optimized portfolio is illustrated.Screen 1201 shows exemplary values that the user may select using theCVaR percentile widget 1205, the CVaR threshold widget 1210, and theinvestment time period widget 1215. The user may utilize an expectedreturn widget 1220 to view the expected return (e.g., −6.61%) of theoptimized portfolio, the expected return (e.g., 0.81%) of the originalportfolio before changes to the portfolio securities weights, and thedifference in the expected return (e.g., −7.43%) between the twoportfolios. The user may utilize a drawdown widget 1225 to view theexpected loss (e.g., −7.00%) at the worst CVaR percentile outcomes forthe optimized portfolio, the expected loss (e.g., −8.35%) at the worstCVaR percentile outcomes for the original portfolio before changes tothe portfolio securities weights, and the difference in the expectedloss at the worst CVaR percentile outcomes (e.g., 1.35) between the twoportfolios. The user may utilize a return volatility widget 1230 to viewthe return volatility (e.g., 3.62%) of the optimized portfolio, thereturn volatility (e.g., 3.80%) of the original portfolio before changesto the portfolio securities weights, and the difference in the returnvolatility (e.g., −0.19%) between the two portfolios. The user mayutilize a returns distribution widget 1235 to view how the returnsdistribution of the optimized portfolio compares to the returnsdistribution of the original portfolio before changes to the portfoliosecurities weights. The user may utilize a portfolio securities weightswidget 1240 to view and/or modify portfolio securities weights ofindividual portfolio securities of the optimized portfolio. The user mayutilize a portfolio securities returns widget 1245 to view expectedreturns of individual portfolio securities of the optimized portfolio.The user may utilize an execute widget 1255 to initiate the execution oftradeable buy and/or sell transactions utilized to create the optimizedportfolio.

FIG. 13 shows a datagraph illustrating data flow(s) for the MLPO. InFIG. 13, dashed lines indicate data flow elements that may be morelikely to be optional. In FIG. 13, a user client 1304 (e.g., of a user)may send a predefined scenario construction request 1321 to a MLPOserver 1306 to facilitate constructing a predefined scenario (e.g., aset of customized market factors used to generate a set of filteredsimulated market scenarios). For example, the user client may be adesktop, a laptop, a tablet, a smartphone, a smartwatch, and/or the likethat is executing a client application. In some alternative embodiments,the predefined scenario construction request may instead be sent by anadministrative client 1302 (e.g., of an administrative user). In oneimplementation, the predefined scenario construction request may includedata such as a request identifier, a user identifier, a predefinedscenario identifier, a simulation model, a pricing date, and/or thelike. In one embodiment, the user client may provide the followingexample predefined scenario construction request, substantially in theform of a HTTP(S) POST message including XML-formatted data, as providedbelow:

POST /predefined_scenario_construction_request.php HTTP/1.1 Host:www.server.com Content-Type: Application/XML Content-Length: 667 <?XMLversion = “1.0” encoding = “UTF-8”?><predefined_scenario_construction_request><request_identifier>ID_request_21</request_identifier><user_identifier>ID_user_1</user_identifier><predefined_scenario_identifier> ID_predefined_scenario_1</predefined_scenario_identifier><simulation_model>ID_neural_network_simulation_model_1Y</simulation_model><pricing_date>2020-04-17</pricing_date></predefined_scenario_construction_request>

The MLPO server 1306 may send a scenario results retrieve request 1325to a repository 1310 to facilitate retrieving simulated market scenariosassociated with the specified simulation. In one implementation, thescenario results retrieve request may include data such as a requestidentifier, a simulation identifier (e.g., determined based on thespecified pricing date and/or simulation model), a set of simulatedmarket scenarios (e.g., filtered), and/or the like. In one embodiment,the MLPO server may provide the following example scenario resultsretrieve request, substantially in the form of a HTTP(S) POST messageincluding XML-formatted data, as provided below:

POST /scenario_results_retrieve_request.php HTTP/1.1 Host:www.server.com Content-Type: Application/XML Content-Length: 667 <?XMLversion = “1.0” encoding = “UTF-8”?> <scenario_results_retrieve_request><request_identifier>ID_request_22</request_identifier><simulation_identifier>ID_sim_1</simulation_identifier><scenario_identifiers>ALL</scenario_identifiers></scenario_results_retrieve_request>

The repository 1310 may send a scenario results retrieve response 1329to the MLPO server 1306 with the requested simulated market scenariosdata. In one implementation, the scenario results retrieve response mayinclude data such as a response identifier, the requested simulatedmarket scenarios data, and/or the like. In one embodiment, therepository may provide the following example scenario results retrieveresponse, substantially in the form of a HTTP(S) POST message includingXML-formatted data, as provided below:

POST /scenario_results_retrieve_response.php HTTP/1.1 Host:www.server.com Content-Type: Application/XML Content-Length: 667 <?XMLversion = “1.0” encoding = “UTF-8”?><scenario_results_retrieve_response><response_identifier>ID_response_22</response_identifier><scenarios_data> <scenario_data><scenario_identifier>ID_scenario_1</scenario_identifier> <market_factor><market_factor_identifier>ID_interest_rate_5Y</market_factor_identifier><market_factor_change>25 basis points</market_factor_change></market_factor> <market_factor><market_factor_identifier>ID_oil_price</market_factor_identifier><market_factor_change>$10</market_factor_change> </market_factor> ...</scenario_data> <scenario_data><scenario_identifier>ID_scenario_2</scenario_identifier> <market_factor><market_factor_identifier>ID_interest_rate_5Y</market_factor_identifier><market_factor_change>50 basis points</market_factor_change></market_factor> <market_factor><market_factor_identifier>ID_oil_price</market_factor_identifier><market_factor_change>$15</market_factor_change> </market_factor> ...</scenario_data> ... </scenarios_data></scenario_results_retrieve_response>

A predefined scenario constructing (PSC) component 1333 may utilize dataprovided in the predefined scenario construction request, data providedin the scenario results retrieve response, and/or data provided viascenario customization input to construct the predefined scenario. SeeFIGS. 14A-B for additional details regarding the PSC component.

The user client 1304 may send a scenario customization input 1337 to theMLPO server 1306 to specify a range of values for a customized marketfactor. In some alternative embodiments, the scenario customizationinput may instead be sent by the administrative client 1302. In oneimplementation, the scenario customization input may include data suchas a request identifier, a market factor identifier, a minimum rangevalue, a maximum range value, and/or the like. In one embodiment, theuser client may provide the following example scenario customizationinput, substantially in the form of a HTTP(S) POST message includingXML-formatted data, as provided below:

POST /scenario_customization_input.php HTTP/1.1 Host: www.server.comContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <scenario_customization_input><request_identifier>ID_request_23</request_identifier><market_factor_identifier>ID_oil_price</market_factor_identifier><minimum_range_value>−49.00</minimum_range_value><maximum_range_value>19992.00</maximum_range_value></scenario_customization_input>

The MLPO server 1306 may send a scenario customization output 1341 tothe user client 1304 to inform the user how ranges of values for othermarket factors have been affected by the change to the customized marketfactor. In some alternative embodiments, the scenario customizationoutput may instead be sent to the administrative client 1302. In oneimplementation, the scenario customization output may include data suchas a response identifier, ranges of values for market factors, and/orthe like. In one embodiment, the MLPO server may provide the followingexample scenario customization output, substantially in the form of aHTTP(S) POST message including XML-formatted data, as provided below:

POST /scenario_customization_output.php HTTP/1.1 Host: www.server.comContent-Type: Application/XML Content-Length: 667 <?XML version = “1.0”encoding = “UTF-8”?> <scenario_customization_output><response_identifier>ID_response_23</response_identifier><market_factors> <market_factor><market_factor_identifier>ID_interest_rate_5Y</market_factor_identifier><minimum_range_value>−115.00</minimum_range_value><maximum_range_value>314.00</maximum_range_value><average_range_value>75.03</average_range_value> </market_factor><market_factor><market_factor_identifier>ID_oil_price</market_factor_identifier><minimum_range_value>−49.00</minimum_range_value><maximum_range_value>19992.00</maximum_range_value><average_range_value>2698.92</average_range_value> </market_factor> ...</market_factors> </scenario_customization_output>

The MLPO server 1306 may send a predefined scenario store request 1345to the repository 1310 to facilitate storing the constructed predefinedscenario. In one implementation, the predefined scenario may be storedas a set of customized market factors and specified ranges of values forcustomized market factors in the set, and the predefined scenario storerequest may include data such as a request identifier, a useridentifier, a predefined scenario identifier, a simulation model, apricing date, ranges of values for market factors, and/or the like. Inone embodiment, the MLPO server may provide the following examplepredefined scenario store request, substantially in the form of aHTTP(S) POST message including XML-formatted data, as provided below:

POST /predefined_scenario_store_request.php HTTP/1.1 Host:www.server.com Content-Type: Application/XML Content-Length: 667 <?XMLversion = “1.0” encoding = “UTF-8”?> <predefined_scenario_store_request><request_identifier>ID_request_24</request_identifier><user_identifier>ID_user_1</user_identifier><predefined_scenario_identifier> ID_predefined_scenario_1</predefined_scenario_identifier><simulation_model>ID_neural_network_simulation_model_1Y</simulation_model><pricing_date>2020-04-17</pricing_date> <customized_market_factors><customized_market_factor><market_factor_identifier>ID_oil_price</market_factor_identifier><minimum_range_value>−49.00</minimum_range_value><maximum_range_value>19992.00</maximum_range_value><average_range_value>2698.92</average_range_value></customized_market_factor> <customized_market_factor><market_factor_identifier>ID_interest_rate_6M</market_factor_identifier><minimum_range_value>40.00</minimum_range_value><maximum_range_value>333.00</maximum_range_vaiue><average_range_value>132.76</average_range_value></customized_market_factor> </customized_market_factors></predefined_scenario_store_request>In another implementation, the predefined scenario may be stored as aset of simulated market scenarios that satisfy specified ranges ofvalues for customized market factors, and the predefined scenario storerequest may include data such as a request identifier, a useridentifier, a predefined scenario identifier, a simulation identifier, aset of simulated market scenarios (e.g., filtered), and/or the like. Inone embodiment, the MLPO server may provide the following examplepredefined scenario store request, substantially in the form of aHTTP(S) POST message including XML-formatted data, as provided below:

POST /predefined_scenario_store_request.php HTTP/1.1 Host:www.server.com Content-Type: Application/XML Content-Length: 667 <?XMLversion = “1.0” encoding = “UTF-8”?> <predefined_scenario_store_request><request_identifier>ID_request_24</request_identifier><user_identifier>ID_user_1</user_identifier><predefined_scenario_identifier> ID_predefined_scenario_1</predefined_scenario_identifier><simulation_identifier>ID_sim_1</simulation_identifier><scenario_identifiers>ID_scenario_1, ID_scenario_2,...</scenario_identifiers> </predefined_scenario_store_request>

The repository 1310 may send a predefined scenario store response 1349to the MLPO server 1306 to confirm that the constructed predefinedscenario was stored successfully. In one implementation, the predefinedscenario store response may include data such as a response identifier,a status, and/or the like. In one embodiment, the repository may providethe following example predefined scenario store response, substantiallyin the form of a HTTP(S) POST message including XML-formatted data, asprovided below:

POST /predefined_scenario_store_response.php HTTP/1.1 Host:www.server.com Content-Type: Application/XML Content-Length: 667 <?XMLversion = “1.0” encoding = “UTF-8”?><predefined_scenario_store_response><response_identifier>ID_response_24</response_identifier><status>OK</status> </predefined_scenario_store_response>

The MLPO server 1306 may send a predefined scenario constructionresponse 1353 to the user client 1304 to inform the user that theconstructed predefined scenario was stored successfully. In somealternative embodiments, the predefined scenario construction responsemay instead be sent to the administrative client 1302. In oneimplementation, the predefined scenario construction response mayinclude data such as a response identifier, a status, and/or the like.In one embodiment, the MLPO server may provide the following examplepredefined scenario construction response, substantially in the form ofa HTTP(S) POST message including XML-formatted data, as provided below:

POST /predefined_scenario_construction_response.php HTTP/1.1 Host:www.server.com Content-Type: Application/XML Content-Length: 667 <?XMLversion = “1.0” encoding = “UTF-8”?><predefined_scenario_construction_response><response_identifier>ID_response_21</response_identifier><status>OK</status> </predefined_scenario_construction_response>

FIGS. 14A-B show a logic flow illustrating embodiments of a predefinedscenario constructing (PSC) component for the MLPO. In FIG. 14A, apredefined scenario construction request may be obtained at 1401. Forexample, the predefined scenario construction request may be obtained asa result of a user requesting construction of a predefined scenario.

Market scenarios to utilize for constructing the predefined scenario maybe determined at 1405. In one embodiment, the market scenarios toutilize may be determined based on the simulation model (e.g., for aspecified pricing date) and/or time period length selected by the user.In another embodiment, the market scenarios to utilize may be determinedbased on filters applied to simulated market scenarios. In oneimplementation, the predefined scenario construction request may beparsed (e.g., using PHP commands) to determine the market scenarios toutilize (e.g., based on the values of the simulation_model and/orpricing_date fields). For example, the selected simulation model and/orpricing date may be used to determine a simulation identifier (e.g.,ID_sim_1) of the corresponding simulation (e.g., a set of simulatedmarket scenarios).

The market scenarios to utilize may be retrieved from a database at1409. In one implementation, the market scenarios to utilize may beretrieved via a scenario results retrieve request.

Market factors to process may be determined at 1413. For example, marketfactors may include interest rates, credit spread, oil price, equityindices, and/or the like. In one implementation, the market factors toprocess may be determined based on market factors utilized in thesimulation. For example, the market factors to process may be determinedvia a MySQL database command similar to the following:

SELECT scenarioMarketFactorID FROM ScenarioResults WHERE simulationID =ID_sim_1;In another implementation, a set of default market factors to processmay be specified in a configuration setting.

A determination may be made at 1417 whether there remain market factorsto process. In one implementation, each of the market factors may beprocessed. If there remain market factors to process, the next marketfactor (e.g., 6 month change in oil price) may be selected forprocessing at 1421.

A factor group for the selected market factor may be determined at 1425.In one embodiment, market factors may be organized into factor groups tofacilitate searching for market factors by the user. For example, thechange in oil prices market factor may be associated with the Macrofactor group. In one implementation, the factor group associated witheach market factor may be specified in a configuration setting. In someimplementations, multiple factor groups may be associated with a marketfactor.

A range of market factor values for the selected market factor may bedetermined at 1429. For example, the range may include a minimum marketfactor value, a maximum market factor value, an average market factorvalue, and/or the like for the market scenarios to utilize. In oneimplementation, the range of market factor values for each market factormay be precalculated. For example, the range of market factor values forthe selected market factor may be determined via a MySQL databasecommand similar to the following:

SELECT simulationMarketFactorRangeMin, simulationMarketFactorRangeMax,simulationMarketFactorRangeAverage FROM ScenarioResults WHEREsimulationID = ID_sim_1 AND scenarioMarketFactorID = ID_oil_price;In another implementation, the range of market factor values for eachmarket factor may be determined by iterating through the marketscenarios to utilize and calculating the range based on the marketfactor values for the market scenarios to utilize. For example, therange of market factor values for the selected market factor may bedetermined via a MySQL database command similar to the following:

SELECT MIN(scenarioSimulatedMarketFactorChange),MAX(scenarioSimulatedMarketFactorChange),AVG(scenarioSimulatedMarketFactorChange) FROM ScenarioResults WHEREsimulationID = ID_sim_1 AND scenarioMarketFactorID = ID_oil_price;

A set of customized market factors may be determined at 1433. Forexample, a market factor may be customized by specifying a subrange ofallowable values for the market factor. In one embodiment, the user mayutilize a user interface widget to create a new predefined scenario(e.g., with no customized market factors). In another embodiment, theuser may utilize a user interface widget to select an existingpredefined scenario with a set of customized market factors. In oneimplementation, the set of customized market factors for a predefinedscenario (e.g., with identifier ID_predefined_scenario_1) may beretrieved from a database. For example, the set of customized marketfactors for the predefined scenario may be determined via a MySQLdatabase command similar to the following:

SELECT customizedMarketFactorID FROM PredefinedScenarios WHEREpredefinedScenarioID = ID_predefined_scenario_1;

The market scenarios to utilize may be filtered based on the set ofcustomized market factors at 1437. In one embodiment, the marketscenarios to utilize may be filtered to the subset of market scenariosthat satisfy the subrange of allowable values for each customized marketfactor. See FIG. 14B for additional details regarding filtering themarket scenarios to utilize based on customized market factors.

A determination may be made at 1441 whether there remain market factorsto process. In one implementation, each of the market factors may beprocessed to determine ranges for the filtered market scenarios. Ifthere remain market factors to process, the next market factor (e.g., 6month change in oil price) may be selected for processing at 1445.

A determination may be made at 1449 whether there remain filtered marketscenarios to analyze. In one implementation, each of the filtered marketscenarios may be analyzed. If there remain filtered market scenarios toanalyze, the next filtered market scenario (e.g., with identifierID_scenario_1) may be selected for analysis at 1453.

A market factor value of the selected market factor for the selectedfiltered market scenario may be determined at 1457. In oneimplementation, the market factor value may be retrieved from adatabase. For example, the market factor value of the selected marketfactor for the selected market scenario may be determined via a MySQLdatabase command similar to the following:

SELECT scenarioSimulatedMarketFactorChange FROM ScenarioResults WHEREsimulationID = ID_sim_1 AND scenarioID = ID_scenario_1 ANDscenarioMarketFactorID = ID_oil_price;

The determined market factor values may be analyzed to determine a rangeof filtered market factor values for the selected market factor at 1461.For example, the range may include a minimum market factor value, amaximum market factor value, an average market factor value, and/or thelike for the filtered market scenarios.

A visualization of the market factors may be generated at 1465. In oneembodiment, the visualization may show the range of unfiltered marketfactor values and/or the range of filtered market factor values for eachof the market factors. In one implementation, a user interface widgetmay be generated for each of the market factors showing the range ofunfiltered market factor values and/or the range of filtered marketfactor values for the respective market factor. See FIGS. 15-19 forexamples of visualizations that may be generated.

A determination may be made at 1469 whether a scenario customizationinput was obtained from the user. In one embodiment, the scenariocustomization input may be a user interface input from the user with auser-specified range of allowable values for an updated market factor.If a scenario customization input was obtained, the specified range ofallowable values for the updated market factor may be determined at1473. For example, the user may specify an updated subrange of allowablevalues for a customized market factor (e.g., an existing customizedmarket factor, a newly customized market factor). In another example,the user may specify that a previously customized market factor shouldno longer be customized (e.g., by updating the subrange of allowablevalues to the full range for the previously customized market factor).In one implementation, the scenario customization input may be parsed(e.g., using PHP commands) to determine the specified range of allowablevalues for the updated market factor (e.g., based on the values of themarket_factor_identifier, minimum_range_value, and/ormaximum_range_value fields). The set of customized market factors may beupdated at 1477. In one embodiment, a newly customized market factor maybe added to the set of customized market factors. In another embodiment,a previously customized market factor may be removed from the set ofcustomized market factors. In one implementation, a list (e.g., an arrayof market factor identifiers, a map of market factor identifier valuesto customized status Boolean values) of customized market factors may beupdated. The market scenarios to utilize may be filtered based on theupdated set of customized market factors and an updated visualization ofthe market factors may be generated as discussed with regard to1437-1465.

A determination may be made at 1481 whether a scenario save input wasobtained from the user. In one embodiment, the scenario save input maybe a user interface input from the user indicating that the predefinedscenario should be saved. If a scenario save input was obtained, thepredefined scenario may be stored at 1485. In one implementation, thepredefined scenario may be stored via a predefined scenario storerequest.

FIG. 14B shows additional details regarding filtering the marketscenarios to utilize based on customized market factors. In FIG. 14B,filtered market scenarios (e.g., an array of filtered market scenarioidentifiers, a map of market scenario identifier values to filteredstatus Boolean values) may be set to the market scenarios to utilize at1402 (e.g., to clear any previously set filters).

A determination may be made at 1406 whether there remain customizedmarket factors to process. In one implementation, each of the marketfactors in the set of customized market factors may be processed. Ifthere remain customized market factors to process, the next customizedmarket factor may be selected for processing at 1410.

The specified range of allowable values for the selected customizedmarket factor may be determined at 1414. For example, the specifiedrange of allowable values may include a minimum value and a maximumvalue. In one implementation, the specified range of allowable valuesfor the selected customized market factor may be determined as discussedwith regard to 1473 (e.g., for a new user-specified range). In anotherimplementation, the specified range of allowable values for the selectedcustomized market factor may be retrieved from a database (e.g., for anexisting predefined scenario). For example, the specified range ofallowable values for the selected customized market factor may bedetermined via a MySQL database command similar to the following:

SELECT customizedMarketFactorRangeMin, customizedMarketFactorRangeMaxFROM PredefinedScenarios WHERE predefinedScenarioID =ID_predefined_scenario_1;

A determination may be made at 1418 whether there remain filtered marketscenarios to analyze. In one implementation, each of the marketscenarios that have not been removed from the filtered market scenarios(e.g., during processing of previously processed customized marketfactors) may be analyzed. If there remain filtered market scenarios toanalyze, the next filtered market scenario may be selected for analysisat 1422.

A market factor value of the selected customized market factor for theselected filtered market scenario may be determined at 1426. In oneimplementation, the market factor value may be retrieved from adatabase. For example, the market factor value of the selectedcustomized market factor for the selected filtered market scenario maybe determined via a MySQL database command similar to the following:

SELECT scenarioSimulatedMarketFactorChange FROM ScenarioResults WHEREsimulationID = ID_sim_1 AND scenarioID = ID_scenario_1 ANDscenarioMarketFactorID = ID_oil_price;

A determination may be made at 1430 whether the determined market factorvalue is in the specified range of allowable values for the selectedcustomized market factor. If the determined market factor value isoutside the specified range of allowable values for the selectedcustomized market factor, the selected filtered market scenario may beremoved from the filtered market scenarios at 1434.

Once the customized market factors have been processed, the remainingfiltered market scenarios may be returned at 1438. In one embodiment,the returned filtered market scenarios are market scenarios havingmarket factor values that fall within the subrange of allowable valuesfor each of the market factors in the set of customized market factors.

FIG. 15 shows a screenshot illustrating user interface(s) of the MLPO.In FIG. 15, an exemplary user interface (e.g., for a mobile device, fora website) for constructing a predefined scenario is illustrated. Screen1501 shows that a user may utilize a load predefined scenario widget1505 to select an existing predefined scenario (e.g., from predefinedscenarios associated with the user's user identifier). The user mayutilize an add new predefined scenario widget 1510 to create a newpredefined scenario.

The user may utilize a pricing date widget 1515 and/or a simulationmodel widget 1520 to specify market scenarios to utilize. The user maysearch through market factors associated with the market scenarios toutilize by filtering displayed market factors using factor group filterwidgets (e.g., 1525A-D). For example, utilizing All factor group widget1525A may show unfiltered market factors associated with the marketscenarios to utilize. In another example, utilizing Macro factor groupwidget 1525D may filter market factors to show market factors associatedwith the Macro factor group (e.g., change in oil price). The user maysearch through market factors associated with the market scenarios toutilize by filtering displayed market factors by market factor nameusing search by factor name widget 1527.

The user may view and/or modify ranges of allowable values for eachmarket factor using market factor widgets (e.g., 1530A-C). For example,screen 1501 shows that ranges of allowable values for the market factorshave not been modified (e.g., there are no customized market factors).

FIG. 16 shows a screenshot illustrating user interface(s) of the MLPO.In FIG. 16, an exemplary user interface (e.g., for a mobile device, fora website) for constructing a predefined scenario is illustrated. Screen1601 shows that the user may modify ranges of allowable values formarket factors of a predefined scenario (e.g., an existing predefinedscenario selected using the load predefined scenario widget 1605, a newpredefined scenario created using the add new predefined scenario widget1610) using allowable range widgets (e.g., 1635A-C). Screen 1601 showsthat when the user modifies the range of allowable values for a marketfactor, an updated visualization showing how ranges of allowable valuesfor the market factors have been affected may be generated. For example,if the user modifies (e.g., using widget 1635B) the range of allowablevalues for the 6 month interest rate market factor (e.g., shown inwidget 1630B (e.g., rearranged in order and/or highlighted to indicate acustomized market factor)), an updated visualization showing how therange of allowable values (e.g., shown in widget 1635A) for the 3 monthinterest rate market factor (e.g., shown in widget 1630A) and how therange of allowable values (e.g., shown in widget 1635C) for the 1 yearinterest rate market factor (e.g., shown in widget 1630C) have changedbased on the user-specified scenario customization input may begenerated.

FIG. 17 shows a screenshot illustrating user interface(s) of the MLPO.In FIG. 17, an exemplary user interface (e.g., for a mobile device, fora website) for constructing a predefined scenario is illustrated. Screen1701 shows that the user may utilize the Macro factor group widget 1725Dto view how the ranges of allowable values (e.g., shown in widgets1735D-F) for market factors associated with the Macro factor group(e.g., shown in widget 1730D-F) have changed based on the user-specifiedscenario customization input.

FIG. 18 shows a screenshot illustrating user interface(s) of the MLPO.In FIG. 18, an exemplary user interface (e.g., for a mobile device, fora website) for constructing a predefined scenario is illustrated. Screen1801 shows that when the user modifies the range of allowable values foranother market factor (e.g., associated with the Macro factor group), anupdated visualization showing how ranges of allowable values for themarket factors have been affected (e.g., based on both modifications)may be generated. For example, if the user modifies (e.g., using widget1835D) the range of allowable values for the oil price market factor(e.g., shown in widget 1830D (e.g., rearranged in order and/orhighlighted to indicate a customized market factor)), an updatedvisualization showing how the range of allowable values (e.g., shown inwidget 1835E) for the VIX market factor (e.g., shown in widget 1830E)and how the range of allowable values (e.g., shown in widget 1835F) forthe Commodities market factor (e.g., shown in widget 1830F) have changedbased on the two user-specified scenario customization inputs may begenerated.

FIG. 19 shows a screenshot illustrating user interface(s) of the MLPO.In FIG. 19, an exemplary user interface (e.g., for a mobile device, fora website) for constructing a predefined scenario is illustrated. Screen1901 shows that the user may utilize the All factor group widget 1925Ato view how the ranges of allowable values for the market factors havechanged based on the user-specified scenario customization inputs. Forexample, market factor widget 1930A shows how the range of allowablevalues (e.g., shown in widget 1935A) for the 3 month interest ratemarket factor has changed based on the user-specified changes to therange of allowable values (e.g., shown in widget 1935B) for the 6 monthinterest rate market factor (e.g., shown in widget 1930B) and to therange of allowable values (e.g., shown in widget 1935D) for the oilprice market factor (e.g., shown in widget 1930D). The user may save thepredefined scenario using a save widget 1940.

FIG. 20 shows a datagraph illustrating data flow(s) for the MLPO. InFIG. 20, dashed lines indicate data flow elements that may be morelikely to be optional. In FIG. 20, a user client 2004 (e.g., of a user)may send a portfolio returns visualization request 2021 to a MLPO server2006 to facilitate generating a portfolio returns visualization based oncustomized market factors. For example, the user client may be adesktop, a laptop, a tablet, a smartphone, a smartwatch, and/or the likethat is executing a client application. In one implementation, theportfolio returns visualization request may include data such as arequest identifier, a user identifier, a predefined scenario identifier,a simulation model, a pricing date, a portfolio identifier, and/or thelike. In one embodiment, the user client may provide the followingexample portfolio returns visualization request, substantially in theform of a HTTP(S) POST message including XML-formatted data, as providedbelow:

POST /portfolio_returns_visualization_request.php HTTP/1.1 Host:www.server.com Content-Type: Application/XML Content-Length: 667 <?XMLversion = “1.0” encoding = “UTF-8”?><portfolio_returns_visualization_request><request_identifier>ID_request_31</request_identifier><user_identifier>ID_user_1</user_identifier><predefined_scenario_identifier> ID_predefined_scenario_1</predefined_scenario_identifier><simulation_model>ID_neural_network_simulation_model_1Y</simulation_model><pricing_date>2020-04-17</pricing_date><portfolio_identifier>ID_portfolio_1</portfolio_identifier></portfolio_returns_visualization_request>

The MLPO server 2006 may send an expected returns retrieve request 2023to a repository 2010 to facilitate retrieving expected returns forsecurities in the portfolio for simulated scenarios corresponding to thespecified simulation (e.g., with a simulation identifier determinedbased on the specified pricing date and/or simulation model). In oneimplementation, the expected returns retrieve request may include datasuch as a request identifier, expected returns to retrievespecification, and/or the like. In one embodiment, the MLPO server mayprovide the following example expected returns retrieve request,substantially in the form of a HTTP(S) POST message includingXML-formatted data, as provided below:

POST /expected_returns_retrieve_request.php HTTP/1.1 Host:www.server.com Content-Type: Application/XML Content-Length: 667 <?XMLversion = “1.0” encoding = “UTF-8”?> <expected_returns_retrieve_request><request_identifier>ID_request_32</request_identifier><expected_returns_specification><simulation_identifier>ID_sim_1</simulation_identifier> <scenario><scenario_identifier>ID_scenario_1</scenario_identifier><securities>MSFT, AAPL, ...</securities> </scenario> <scenario><scenario_identifier>ID_scenario_2</scenario_identifier><securities>MSFT, AAPL, ...</securities> </scenario> ...</expected_returns_specification> </expected_returns_retrieve_request>

The repository 2010 may send an expected returns retrieve response 2025to the MLPO server 2006 with the requested expected returns data. In oneimplementation, the expected returns retrieve response may include datasuch as a response identifier, the requested expected returns data,and/or the like. In one embodiment, the repository may provide thefollowing example expected returns retrieve response, substantially inthe form of a HTTP(S) POST message including XML-formatted data, asprovided below:

POST /expected_returns_retrieve_response.php HTTP/1.1 Host:www.server.com Content-Type: Application/XML Content-Length: 667 <?XMLversion = “1.0” encoding = “UTF-8”?><expected_returns_retrieve_response><response_identifier>ID_response_32</response_identifier><expected_returns> <scenario><scenario_identifier>ID_scenario_1</scenario_identifier> <security><security_identifier>MSFT</security_identifier><expected_return>10%</expected_return> </security> <security><security_identifier>AAPL</security_identifier><expected_return>12%</expected_return> </security> ... </scenario><scenario> <scenario_identifier>ID_scenario_2</scenario_identifier><security> <security_identifier>MSFT</security_identifier><expected_return>15%</expected_return> </security> <security><security_identifier>AAPL</security_identifier><expected_return>13%</expected_return> </security> ... </scenario> ...</expected_returns> </expected_returns_retrieve_response>

The MLPO server 2006 may send a predefined scenario retrieve request2027 to the repository 2010 to facilitate retrieving the specifiedpredefined scenario. In one implementation, the predefined scenarioretrieve request may include data such as a request identifier, a useridentifier, a predefined scenario identifier, and/or the like. In oneembodiment, the MLPO server may provide the following example predefinedscenario retrieve request, substantially in the form of a HTTP(S) POSTmessage including XML-formatted data, as provided below:

POST /predefined_scenario_retrieve_request.php HTTP/1.1 Host:www.server.com Content-Type: Application/XML Content-Length: 667 <?XMLversion = “1.0” encoding = “UTF-8”?><predefined_scenario_retrieve_request><request_identifier>ID_request_33</request_identifier><user_identifier>ID_user_1</user_identifier><predefined_scenario_identifier> ID_predefined_scenario_1</predefined_scenario_identifier></predefined_scenario_retrieve_request>

The repository 2010 may send a predefined scenario retrieve response2029 to the MLPO server 2006 with the requested predefined scenariodata. In one implementation, the predefined scenario retrieve responsemay include data such as a response identifier, the requested predefinedscenario data, and/or the like. In one embodiment, the repository mayprovide the following example predefined scenario retrieve response,substantially in the form of a HTTP(S) POST message includingXML-formatted data, as provided below:

POST /predefined_scenario_retrieve_response.php HTTP/1.1 Host:www.server.com Content-Type: Application/XML Content-Length: 667 <?XMLversion = “1.0” encoding = “UTF-8”?><predefined_scenario_retrieve_response><response_identifier>ID_response_33</response_identifier><customized_market_factors> <customized_market_factor><market_factor_identifier>ID_oil_price</market_factor_identifier><minimum_range_value>−49.00</minimum_range_value><maximum_range_value>19992.00</maximum_range_value><average_range_value>2698.92</average_range_value></customized_market_factor> <customized_market_factor><market_factor_identifier>ID_interest_rate_6M</market_factor_identifier><minimum_range_value>40.00</minimum_range_value><maximum_range_value>333.00</maximum_range_value><average_range_value>132.76</average_range_value></customized_market_factor> </customized_market_factors></predefined_scenario_retrieve_response>

A scenario based portfolio returns visualizing (SPRV) component 2033 mayutilize data provided in the portfolio returns visualization request togenerate a portfolio return metrics visualization. See FIG. 21 foradditional details regarding the SPRV component.

The MLPO server 2006 may send a portfolio returns visualization response2037 to the user client 2004 to provide a visualization of portfolioreturn metrics for the specified portfolio under the specifiedpredefined scenario. In one implementation, the portfolio returnsvisualization response may include data such as a response identifier,visualization data, and/or the like. In one embodiment, the MLPO servermay provide the following example portfolio returns visualizationresponse, substantially in the form of a HTTP(S) POST message includingXML-formatted data, as provided below:

POST /portfolio_returns_visualization_response.php HTTP/1.1 Host:www.server.com Content-Type: Application/XML Content-Length: 667 <?XMLversion = “1.0” encoding = “UTF-8”?><portfolio_returns_visualization_response><response_identifier>ID_response_31</response_identifier><visualization_data> portfolio return metrics data (e.g., constituentsecurities' and/or portfolio's returns, worst returns, returnvolatility, frequency vs. returns data) </visualization_data></portfolio_returns_visualization_response>

If the user customizes a market factor, the user client 2004 may send avisualization scenario customization input 2041 to the MLPO server 2006specifying a range of values for the customized market factor (e.g., tomodify the predefined scenario). In one implementation, thevisualization scenario customization input may include data such as arequest identifier, a market factor identifier, a minimum range value, amaximum range value, and/or the like. In one embodiment, the user clientmay provide the following example visualization scenario customizationinput, substantially in the form of a HTTP(S) POST message includingXML-formatted data, as provided below:

POST /visualization_scenario_customization_input.php HTTP/1.1 Host:www.server.com Content-Type: Application/XML Content-Length: 667 <?XMLversion = “1.0” encoding = “UTF-8”?><visualization_scenario_customization_input><request_identifier>ID_request_34</request_identifier><market_factor_identifier>ID_VIX</market_factor_identifier><minimum_range_value>913.00</minimum_range_value><maximum_range_value>5141.00</maximum_range_value></visualization_scenario_customization_input>

The MLPO server 2006 may send a visualization scenario customizationoutput 2045 to the user client 2004 to provide an updated visualizationof portfolio return metrics for the specified portfolio (e.g., under themodified predefined scenario). In one implementation, the visualizationscenario customization output may include data such as a responseidentifier, visualization data, and/or the like. In one embodiment, theMLPO server may provide the following example visualization scenariocustomization output, substantially in the form of a HTTP(S) POSTmessage including XML-formatted data, as provided below:

POST /visualization_scenario_customization_output.php HTTP/1.1 Host:www.server.com Content-Type: Application/XML Content-Length: 667 <?XMLversion = “1.0” encoding = “UTF-8”?><visualization_scenario_customization_output><response_identifier>ID_response_34</response_identifier><visualization_data> portfolio return metrics data (e.g., constituentsecurities' and/or portfolio's returns, worst returns, returnvolatility, frequency vs. returns data) </visualization_data></visualization_scenario_customization_output>

FIG. 21 shows a logic flow illustrating embodiments of a scenario basedportfolio returns visualizing (SPRV) component for the MLPO. In FIG. 21,a portfolio returns visualization request may be obtained at 2101. Forexample, the portfolio returns visualization request may be obtained asa result of a user requesting generation of a portfolio returnsvisualization.

Market scenarios to utilize for generating the portfolio returnsvisualization may be determined at 2105. In one embodiment, the marketscenarios to utilize may be determined based on the simulation model(e.g., for a specified pricing date) and/or time period length selectedby the user. In another embodiment, the market scenarios to utilize maybe determined based on filters applied to simulated market scenarios. Inone implementation, the portfolio returns visualization request may beparsed (e.g., using PHP commands) to determine the market scenarios toutilize (e.g., based on the values of the simulation_model and/orpricing_date fields). For example, the selected simulation model and/orpricing date may be used to determine a simulation identifier (e.g.,ID_sim_1) of the corresponding simulation (e.g., a set of simulatedmarket scenarios).

Portfolio securities of a portfolio may be determined at 2109 andportfolio securities weights for the portfolio securities may bedetermined at 2113. In one embodiment, the portfolio securities and/orthe corresponding portfolio securities weights may be retrieved from adatabase (e.g., based on a portfolio identifier). In one implementation,the portfolio returns visualization request may be parsed (e.g., usingPHP commands) to determine the portfolio identifier (e.g., based on thevalue of the portfolio_identifier field). In another embodiment, theportfolio securities and/or the corresponding portfolio securitiesweights may be specified by the user. In one implementation, theportfolio returns visualization request may be parsed (e.g., using PHPcommands) to determine the specified portfolio securities and/or thecorresponding portfolio securities weights. In another embodiment, theportfolio securities and/or the corresponding portfolio securitiesweights may be determined based on an optimization. In oneimplementation, the portfolio securities and/or the correspondingportfolio securities weights may be determined as discussed with regardto the PC component.

Expected returns of the portfolio securities for the market scenarios toutilize may be retrieved from a database at 2117. For example, theexpected returns may be cached to facilitate expected return metricscalculations. In one implementation, the expected returns may beretrieved via an expected returns retrieve request.

A determination may be made at 2121 whether there remain portfoliosecurities to process. In one implementation, each of the constituentportfolio securities may be processed. If there remain portfoliosecurities to process, the next security (e.g., with identifier MSFT)may be selected for processing at 2125.

A determination may be made at 2129 whether there remain marketscenarios to analyze. In one implementation, each of the marketscenarios to utilize may be analyzed. If there remain market scenariosto analyze, the next market scenario (e.g., with identifierID_scenario_1) may be selected for analysis at 2133.

An expected return for the selected security for the selected marketscenario may be determined at 2137. In one implementation, the expectedreturn may be retrieved from cache. In another implementation, theexpected return may be retrieved from a database. For example, theexpected return for the selected security for the selected marketscenario may be determined via a MySQL database command similar to thefollowing:

SELECT linkedScenarioSecurityExpectedReturn FROM ExpectedReturns WHEREsecurityID = “MSFT” AND linkedSimulationID = ID_sim_1 ANDlinkedScenarioID = ID_scenario_1;

Expected security return metrics for the selected security for themarket scenarios to utilize may be calculated at 2141. For example, theexpected security return metrics for a security may include thesecurity's expected return, worst returns, return volatility, frequencyvs. returns data, and/or the like. In one implementation, the expectedsecurity return metrics for each security may be determined by iteratingthrough the market scenarios to utilize and calculating the expectedsecurity return metrics based on the expected returns (e.g., cached) forthe market scenarios to utilize. For example, the expected return forthe selected security for the market scenarios to utilize may bedetermined via a MySQL database command similar to the following:

SELECT AVG(linkedScenarioSecurityExpectedReturn) FROM ExpectedReturnsWHERE securityID = “MSFT” AND linkedSimulationID = ID_sim_1;

Expected portfolio return metrics for the portfolio for the marketscenarios to utilize may be calculated at 2145. For example, theexpected portfolio return metrics for a portfolio may include theportfolio's expected return, worst returns, return volatility, frequencyvs. returns data, and/or the like. In various implementations, theexpected portfolio return metrics for the portfolio may be calculatedusing a weighted average (e.g., weighted based on the portfoliosecurities weights) of the expected security returns and/or of thecalculated expected security return metrics for the constituentsecurities of the portfolio. For example, the following API may beutilized to determine the expected portfolio return metrics for theportfolio for the market scenarios to utilize:

Post API/RunAnalysis

-   -   This API facilitates generating portfolio return metrics        visualization for a specified portfolio (e.g., list of        securities). The portfolio return metrics calculation results        are included in the Summary object returned by the API.    -   The API returns HTTP/1.1 status code 201 if the request is        successful. It returns 500 Internal Server Error if there is an        exception.

Input Parameter Details

Attribute name Mandatory Default Description/Rule securityInputs YSpecify the initial investment cash N 0 Integer between 1 and 50 modelIdY 1 Integer, either 1 or 4 based on the model simulationId Y 0 Taxable =1, Tax-Exempt = 0 simulationInputs Y List of factor min and max rangefor filtering of scenarios businessCycleInputs N List of business cycleinputs and associated percentages. (e.g., Late Cycle 50% and Recession50%) pricingDt Y Current Pricing Date for which simulation data isavailable

Request

POST API/runAnalysis Content-type: application/json {  ″securityInputs″: [{          “fmrCusip”: “EAFE”,         “description”:”EAFE”,          “qty”: 200000       }, {         “fmrCusip”: “DHI270000”,          “description”: ″USTB 3.375%11/15/48″,          “qty”: 200000       }      ....   ],   ″cash″: 0,  ″modelId″: 1,   ″simulationId″: 1,   ″pricingDt″: “01/01/2020”,  ″simulationInputs″:[{       “factorName”: ″VIX″,          “rangeStart”: −3544,           “rangeEnd”: 5513        }, {          “factorName”: ″SP500″,           “rangeStart”: −4648,          “rangeEnd”: 2947}    ],   ″businessCycleInputs″: [{           cycleName: ″Late″,            percentage: 100         }, {           cycleName: ″Recession″,            percentage: 0     }]  ...}

Response

201 Content-Type: application/json {  ″summary″: {     “risk”: 234.42.    “avg5Percenti1e”: −202.09   },  “marketReturns”:[ {     ″marketId″:959,     ″bucketId″: 4,     ″marketReturn″: −434.16    },{    ″marketId″: 2527,     ″bucketId″: 6,        ″marketReturn″: −252.16     },       ...     ] }

A visualization of the expected portfolio return metrics for theportfolio and/or of the expected security return metrics for theconstituent securities of the portfolio for the market scenarios toutilize may be generated at 2149. In one implementation, user interfacewidgets showing the expected portfolio return metrics and/or theexpected security return metrics may be generated via a portfolioreturns visualization response. See FIGS. 22-25 for examples ofvisualizations that may be generated.

A determination may be made at 2153 whether a predefined scenarioselection input was obtained from the user. In one embodiment, thepredefined scenario selection input may be a user interface input fromthe user with a user-specified predefined scenario selection. Forexample, the user may select a predefined scenario to determine howexpected portfolio return metrics for the portfolio and/or for theconstituent securities of the portfolio would change with market factorcustomizations specified in the predefined scenario.

If a predefined scenario selection input was obtained, the set ofcustomized market factors associated with the selected predefinedscenario may be determined at 2157. In one implementation, the marketfactor customizations specified in the predefined scenario may beobtained via a predefined scenario retrieve response, and the predefinedscenario retrieve response may be parsed (e.g., using PHP commands) todetermine the set of customized market factors (e.g., based on thevalues of the market_factor_identifier fields).

The market scenarios to utilize may be filtered based on the set ofcustomized market factors at 2161. In one embodiment, the marketscenarios to utilize may be filtered to the subset of market scenariosthat satisfy the subrange of allowable values for each customized marketfactor. See FIG. 14B for additional details regarding filtering themarket scenarios to utilize based on customized market factors. Inanother embodiment, the market scenarios to utilize also may be filteredbased on specified business cycle settings (e.g., as discussed withregard to FIG. 27).

Expected security return metrics for the portfolio securities for thefiltered market scenarios may be calculated at 2165. In oneimplementation, the expected security return metrics for eachconstituent security of the portfolio may be determined by iteratingthrough the filtered market scenarios and calculating the expectedsecurity return metrics based on the expected returns (e.g., cached) forthe filtered market scenarios. For example, the expected return for aconstituent security (e.g., MSFT) of the portfolio for the filteredmarket scenarios may be determined via a MySQL database command similarto the following:

SELECT AVG(linkedScenarioSecurityExpectedReturn) FROM ExpectedReturnsWHERE securityID = “MSFT” AND linkedSimulationID = ID_sim_1 AND linkedScenarioID IN (ID_scenario_1, ID_scenario_2, ... ) ;

Expected portfolio return metrics for the portfolio for the filteredmarket scenarios may be calculated at 2169. In various implementations,the expected portfolio return metrics for the portfolio may becalculated using a weighted average (e.g., weighted based on theportfolio securities weights) of the expected security returns and/or ofthe calculated expected security return metrics for the constituentsecurities of the portfolio (e.g., via the API).

A visualization of the expected portfolio return metrics for theportfolio and/or of the expected security return metrics for theconstituent securities of the portfolio for the filtered marketscenarios may be generated at 2173. In one implementation, userinterface widgets showing the expected portfolio return metrics and/orthe expected security return metrics may be generated (e.g., via aportfolio returns visualization response, via a visualization scenariocustomization output). See FIGS. 22-25 for examples of visualizationsthat may be generated.

A determination may be made at 2177 whether a market factorcustomization input was obtained from the user (e.g., via avisualization scenario customization input). In one embodiment, themarket factor customization input may be a user interface input from theuser with a user-specified range of allowable values for an updatedmarket factor. If a market factor customization input was obtained, thespecified range of allowable values for the updated market factor may bedetermined at 2181. In one implementation, the visualization scenariocustomization input may be parsed (e.g., using PHP commands) todetermine the specified range of allowable values for the updated marketfactor (e.g., based on the values of the market_factor_identifier,minimum_range_value, and/or maximum_range_value fields). The set ofcustomized market factors may be updated at 2185. In one implementation,a list (e.g., an array of market factor identifiers, a map of marketfactor identifier values to customized status Boolean values) ofcustomized market factors may be updated. Market scenarios to utilizemay be filtered based on the updated set of customized market factorsand an updated visualization of the expected portfolio return metricsfor the portfolio and/or of the expected security return metrics for theconstituent securities of the portfolio may be generated as discussedwith regard to 2161-2173.

FIG. 22 shows a screenshot illustrating user interface(s) of the MLPO.In FIG. 22, an exemplary user interface (e.g., for a mobile device, fora website) for generating a portfolio returns visualization for aportfolio is illustrated. Screen 2201 shows that a user may utilize ascenario tab 2205 to specify predefined scenario settings. The user mayutilize a load predefined scenario widget 2210 to select a predefinedscenario (e.g., from predefined scenarios associated with the user'suser identifier) used to filter market scenarios to utilize forgenerating a portfolio returns visualization.

FIG. 23 shows a screenshot illustrating user interface(s) of the MLPO.In FIG. 23, an exemplary user interface (e.g., for a mobile device, fora website) for generating a portfolio returns visualization for aportfolio is illustrated. Screen 2301 shows that the user may utilizemarket factor widgets (e.g., 2305A-B) to view and/or modify ranges ofallowable values for each market factor associated with the marketscenarios to utilize (e.g., based on customizations specified in theselected predefined scenario). For example, market factor widget 2305Ashows some exemplary market factors that may be selected by the user forviewing and/or modification.

FIG. 24 shows a screenshot illustrating user interface(s) of the MLPO.In FIG. 24, an exemplary user interface (e.g., for a mobile device, fora website) for generating a portfolio returns visualization for aportfolio is illustrated. For example, screen 2401 shows that the usermay utilize a market factor widget 2405A to view ranges of allowablevalues (e.g., based on customizations specified in the selectedpredefined scenario) for the VIX market factor using an allowable rangewidget 2410A, and a market factor widget 2405B to view ranges ofallowable values (e.g., based on customizations specified in theselected predefined scenario) for the SP500 market factor using anallowable range widget 2410B.

Screen 2401 shows that the user may utilize a drawdown widget 2425 toview the expected loss (e.g., −9.42%) at the worst CVaR percentileoutcomes for the portfolio under the original predefined scenario. Theuser may utilize a return volatility widget 2430 to view the returnvolatility (e.g., 4.15%) of the portfolio under the original predefinedscenario. The user may utilize a returns distribution widget 2435 toview the returns distribution of the portfolio under the originalpredefined scenario. The user may utilize a portfolio securities weightswidget 2440 to view and/or modify portfolio securities weights ofindividual portfolio securities of the portfolio under the originalpredefined scenario. The user may utilize a portfolio securities returnswidget 2445 to view expected returns of individual portfolio securitiesof the portfolio under the original predefined scenario.

FIG. 25 shows a screenshot illustrating user interface(s) of the MLPO.In FIG. 25, an exemplary user interface (e.g., for a mobile device, fora website) for generating a portfolio returns visualization for aportfolio is illustrated. Screen 2501 shows that when the user modifiesthe range of allowable values for a market factor, an updatedvisualization showing how the expected portfolio return metrics for theportfolio and/or the expected security return metrics for theconstituent securities of the portfolio have been affected may begenerated. For example, the user may utilize an allowable range widget2510A to modify the range of allowable values (e.g., a customization)for the VIX market factor. The updated visualization shows how the rangeof allowable values (e.g., shown in an allowable range widget 2510B) forthe SP500 market factor has been affected (e.g., based on the updatedset of filtered market scenarios). The updated visualization shows thatthe user may utilize a drawdown widget 2525 to view the expected loss(e.g., −20.25%) at the worst CVaR percentile outcomes for the portfoliounder the customized predefined scenario, the expected loss (e.g.,−9.42%) at the worst CVaR percentile outcomes for the portfolio underthe original predefined scenario, and the difference in the expectedloss at the worst CVaR percentile outcomes (e.g., −10.83) between thetwo scenarios. The updated visualization shows that the user may utilizea return volatility widget 2530 to view the return volatility (e.g.,4.51%) for the portfolio under the customized predefined scenario, thereturn volatility (e.g., 4.15%) for the portfolio under the originalpredefined scenario, and the difference in the expected returnvolatility (e.g., 0.36%) between the two scenarios. The updatedvisualization shows that the user may utilize a returns distributionwidget 2535 to view the returns distribution for the portfolio under thecustomized predefined scenario, the returns distribution for theportfolio under the original predefined scenario, and the difference inthe expected returns distribution between the two scenarios. The usermay utilize a portfolio securities weights widget 2540 to view and/ormodify portfolio securities weights of individual portfolio securitiesof the portfolio under the customized predefined scenario. The user mayutilize a portfolio securities returns widget 2545 to view expectedreturns of individual portfolio securities of the portfolio under thecustomized predefined scenario. The user may utilize an optimize widget2550 to determine an optimized portfolio under the customized predefinedscenario (e.g., determined based on the updated set of filtered marketscenarios). The user may utilize an execute widget 2555 to initiate theexecution of tradeable buy and/or sell transactions utilized to createthe optimized portfolio under the customized predefined scenario.

FIG. 26 shows a datagraph illustrating data flow(s) for the MLPO. InFIG. 26, dashed lines indicate data flow elements that may be morelikely to be optional. In FIG. 26, an user client 2604 (e.g., of a user)may send a portfolio returns visualization request 2621 to a MLPO server2606 to facilitate generating a portfolio returns visualization based onspecified business cycle settings. For example, the user client may be adesktop, a laptop, a tablet, a smartphone, a smartwatch, and/or the likethat is executing a client application. In one implementation, theportfolio returns visualization request may include data such as arequest identifier, a user identifier, business cycle settings, asimulation model, a pricing date, a portfolio identifier, and/or thelike. In one embodiment, the user client may provide the followingexample portfolio returns visualization request, substantially in theform of a HTTP(S) POST message including XML-formatted data, as providedbelow:

POST /portfolio_returns_visualization_request.php HTTP/1.1 Host:www.server.com Content-Type: Application/XML Content-Length: 667 <?XMLversion = “1.0” encoding = “UTF−8”?><portfolio_returns_visualization_request> <request_identifier>ID_request_41</request_identifier> <user_identifier>ID_user_1</user_identifier>  <business_cycle_settings>  <business_cycle>   <business_cycle_identifier>ID_CYCLE_LATE</business_cycle_identifier>   <business_cycle_weight>100%</business_cycle_weight>  </business_cycle>  </business_cycle_settings> <simulation_model>ID_neural_network_simulation_model_1Y</simulation_model> <pricing_date>2020-04-17<pricing_date> <portfolio_identifier>ID_portfolio_1</portfolio_identifier></portfolio_returns_visualization_request>

The MLPO server 2606 may send an expected returns retrieve request 2623to a repository 2610 to facilitate retrieving expected returns forsecurities in the portfolio for simulated scenarios corresponding to thespecified simulation (e.g., with a simulation identifier determinedbased on the specified pricing date and/or simulation model). In oneimplementation, the expected returns retrieve request may include datasuch as a request identifier, expected returns to retrievespecification, and/or the like. In one embodiment, the MLPO server mayprovide the following example expected returns retrieve request,substantially in the form of a HTTP(S) POST message includingXML-formatted data, as provided below:

POST /expected_returns_retrieve_request.php HTTP/1.0 Host:www.server.com Content-Type: Application/XML Content-Length: 667 <?XMLversion = “1.0” encoding = “UTF−8”?> <expected_returns_retrieve_request> <request_identifier>ID_request_42</request_identifier> <expected_returns_specification>   <simulation_identifier>ID_sim_1</simulation_identifier>    <scenario>    <scenario_identifier>ID_scenario_1</scenario_identifier>    <securities>MSFT, AAPL, ...</securities>    </scenario>   <scenario>    <scenario_identifier>ID_scenario_2</scenario_identifier>    <securities>MSFT, AAPL, ...</securities>    </scenario>   ... </expected_returns_specification> </expected_returns_retrieve_request>

The repository 2610 may send an expected returns retrieve response 2629to the MLPO server 2606 with the requested expected returns data. In oneimplementation, the expected returns retrieve response may include datasuch as a response identifier, the requested expected returns data,and/or the like. In one embodiment, the repository may provide thefollowing example expected returns retrieve response, substantially inthe form of a HTTP(S) POST message including XML-formatted data, asprovided below:

POST /expected_returns_retrieve_response.php HTTP/1.1 Host:www.server.com Content-Type: Application/XML Content-Length: 667 <?XMLversion = “1.0” encoding = “UTF−8”?><expected_returns_retrieve_response> <response_identifier>ID_response_42</response_identifier> <expected_returns>   <scenario>   <scenario_identifier>ID_scenario_1</scenario_identifier>   <security>     <security_identifier>MSFT</security_identifier>     <expected_return>10%</expected_return>     </security>    <security>      <security_identifier>AAPL</security_identifier>     <expected_return>12%</expected_return>     </security>     ...   </scenario>    <scenario>    <scenario_identifier>ID_scenario_2</scenario_identifier>    <security>      <security_identifier>MSFT</security_identifier>     <expected_return>15%</expected_return>     </security>    <security>      <security_identifier>AAPL</security_identifier>     <expected_return>13%</expected_return>     </security>     ...  </scenario>   ...  </expected_returns></expected_returns_retrieve_response>

A business cycle based portfolio returns visualizing (BPRV) component2633 may utilize data provided in the portfolio returns visualizationrequest to generate a portfolio return metrics visualization. See FIG.27 for additional details regarding the BPRV component.

The MLPO server 2606 may send a portfolio returns visualization response2637 to the user client 2604 to provide a visualization of portfolioreturn metrics for the specified portfolio under the specified businesscycle settings. In one implementation, the portfolio returnsvisualization response may include data such as a response identifier,visualization data, and/or the like. In one embodiment, the MLPO servermay provide the following example portfolio returns visualizationresponse, substantially in the form of a HTTP(S) POST message includingXML-formatted data, as provided below:

POST /portfolio_returns_visualization_response.php HTTP/1.1 Host:www.server.com Content-Type: Application/XML Content-Length: 667 <?XMLversion = “1.0” encoding = “UTF−8”?><portfolio_returns_visualization_response> <response_identifier>ID_response_41</response_identifier> <visualization_data>   portfolio return metrics data (e.g., constituentsecurities’   and/or portfolio’s   returns, worst returns, returnvolatility, frequency vs. returns data)  </visualization_data></portfolio_returns_visualization_response>

If the user customizes business cycle settings, the user client 2604 maysend a visualization business cycle customization input 2641 to the MLPOserver 2606 specifying updated business cycle settings. In oneimplementation, the visualization business cycle customization input mayinclude data such as a request identifier, business cycle settings,and/or the like. In one embodiment, the user client may provide thefollowing example visualization business cycle customization input,substantially in the form of a HTTP(S) POST message includingXML-formatted data, as provided below:

POST /visualization_business_cycle_customization_input.php HTTP/1.1Host: www.server.com Content-Type: Application/XML Content-Length: 667<?XML version = “1.0” encoding = “UTF−8”?><visualization_business_cycle_customization_input> <request_identifier>ID_request_43</request_identifier> <business_cycle_settings>   <business_cycle>   <business_cycle_identifier>ID_CYCLE_LATE</business_cycle_identifier>   <business_cycle_weight>85%</business_cycle_weight>  </business_cycle>   <business_cycle>   <business_cycle_identifier>ID_CYCLE_RECESSION</business_cycle_identifier>   <business_cycle_weight>15%</business_cycle_weight>  </business_cycle>  </business_cycle_settings></visualization_business_cycle_customization_input>

The MLPO server 2606 may send a visualization business cyclecustomization output 2645 to the user client 2604 to provide an updatedvisualization of portfolio return metrics for the specified portfolio(e.g., under the modified business cycle settings). In oneimplementation, the visualization business cycle customization outputmay include data such as a response identifier, visualization data,and/or the like. In one embodiment, the MLPO server may provide thefollowing example visualization business cycle customization output,substantially in the form of a HTTP(S) POST message includingXML-formatted data, as provided below:

POST /visualization_business_cycle_customization_output.php HTTP/1.1Host: www.server.com Content-Type: Application/XML Content-Length: 667<?XML version = “1.0” encoding = “UTF−8”?><visualization_business_cycle_customization_output> <response_identifier>ID_response_43</response_identifier> <visualization_data>   portfolio return metrics data (e.g., constituentsecurities′   and/or portfolio′s returns, worst returns,    returnvolatility, frequency vs. returns data)  </visualization_data></visualization_business_cycle_customization_output>

FIG. 27 shows a logic flow illustrating embodiments of a business cyclebased portfolio returns visualizing (BPRV) component for the MLPO. InFIG. 27, a portfolio returns visualization request may be obtained at2701. For example, the portfolio returns visualization request may beobtained as a result of a user requesting generation of a portfolioreturns visualization.

Market scenarios to utilize for generating the portfolio returnsvisualization may be determined at 2705. In one embodiment, the marketscenarios to utilize may be determined based on the simulation model(e.g., for a specified pricing date) and/or time period length selectedby the user. In another embodiment, the market scenarios to utilize maybe determined based on filters applied to simulated market scenarios. Inone implementation, the portfolio returns visualization request may beparsed (e.g., using PHP commands) to determine the market scenarios toutilize (e.g., based on the values of the simulation_model and/orpricing_date fields). For example, the selected simulation model and/orpricing date may be used to determine a simulation identifier (e.g.,ID_sim_1) of the corresponding simulation (e.g., a set of simulatedmarket scenarios).

Portfolio securities of a portfolio may be determined at 2709 andportfolio securities weights for the portfolio securities may bedetermined at 2713. In one embodiment, the portfolio securities and/orthe corresponding portfolio securities weights may be retrieved from adatabase (e.g., based on a portfolio identifier). In one implementation,the portfolio returns visualization request may be parsed (e.g., usingPHP commands) to determine the portfolio identifier (e.g., based on thevalue of the portfolio_identifier field). In another embodiment, theportfolio securities and/or the corresponding portfolio securitiesweights may be specified by the user. In one implementation, theportfolio returns visualization request may be parsed (e.g., using PHPcommands) to determine the specified portfolio securities and/or thecorresponding portfolio securities weights. In another embodiment, theportfolio securities and/or the corresponding portfolio securitiesweights may be determined based on an optimization. In oneimplementation, the portfolio securities and/or the correspondingportfolio securities weights may be determined as discussed with regardto the PC component.

Expected returns of the portfolio securities for the market scenarios toutilize may be retrieved from a database at 2717. For example, theexpected returns may be cached to facilitate expected return metricscalculations. In one implementation, the expected returns may beretrieved via an expected returns retrieve request.

A determination may be made at 2721 whether there remain portfoliosecurities to process. In one implementation, each of the constituentportfolio securities may be processed. If there remain portfoliosecurities to process, the next security (e.g., with identifier MSFT)may be selected for processing at 2725.

A determination may be made at 2729 whether there remain marketscenarios to analyze. In one implementation, each of the marketscenarios to utilize may be analyzed. If there remain market scenariosto analyze, the next market scenario (e.g., with identifierID_scenario_1) may be selected for analysis at 2733.

An expected return for the selected security for the selected marketscenario may be determined at 2737. In one implementation, the expectedreturn may be retrieved from cache. In another implementation, theexpected return may be retrieved from a database. For example, theexpected return for the selected security for the selected marketscenario may be determined via a MySQL database command similar to thefollowing:

SELECT linkedScenarioSecurityExpectedReturn FROM ExpectedReturns WHEREsecurityID = “MSFT” AND linkedSimulationID = ID_sim_1 AND linkedScenarioID = ID_scenario_1;

Expected security return metrics for the selected security for themarket scenarios to utilize may be calculated at 2741. For example, theexpected security return metrics for a security may include thesecurity's expected return, worst returns, return volatility, frequencyvs. returns data, and/or the like. In one implementation, the expectedsecurity return metrics for each security may be determined by iteratingthrough the market scenarios to utilize and calculating the expectedsecurity return metrics based on the expected returns (e.g., cached) forthe market scenarios to utilize. For example, the expected return forthe selected security for the market scenarios to utilize may bedetermined via a MySQL database command similar to the following:

SELECT AVG(linkedScenarioSecurityExpectedReturn) FROM ExpectedReturnsWHERE securityID = “MSFT” AND linkedSimulationID = ID_sim_1;

Expected portfolio return metrics for the portfolio for the marketscenarios to utilize may be calculated at 2745. For example, theexpected portfolio return metrics for a portfolio may include theportfolio's expected return, worst returns, return volatility, frequencyvs. returns data, and/or the like. In various implementations, theexpected portfolio return metrics for the portfolio may be calculatedusing a weighted average (e.g., weighted based on the portfoliosecurities weights) of the expected security returns and/or of thecalculated expected security return metrics for the constituentsecurities of the portfolio. For example, the following API may beutilized to determine the expected portfolio return metrics for theportfolio for the market scenarios to utilize:

Post API/RunAnalysis

-   -   This API facilitates generating portfolio return metrics        visualization for a specified portfolio (e.g., list of        securities). The portfolio return metrics calculation results        are included in the Summary object returned by the API.    -   The API returns HTTP/1.1 status code 201 if the request is        successful. It returns 500 Internal Server Error if there is an        exception.

Input Parameter details

Attribute name Mandatory Default Description/Rule securityInputs YSpecify the initial investment cash N 0 Integer between 1 and 50 modelIdY 1 Integer, either 1 or 4 based on the model simulationId Y 0 Taxable =1, Tax-Exempt = 0 simulationInputs Y List of factor min and max rangefor filtering of scenarios businessCycleInputs N List of business cycleinputs and associated percentages. (e.g., Late Cycle 50% and Recession50%) pricingDt Y Current Pricing Date for which simulation data isavailable

Request

POST API/runAnalysis Content-type: application/json {  ″securityInputs″: [{        “fmrCusip”: “EAFE”,       “description”:“EAFE”,        “qty”: 200000      }, {       “fmrCusip”: “DHI270000”,        “description”: ″USTB 3.375%11/15/48″,        “qty”: 200000      }      ....   ],   ″cash″: 0,  ″modelId″: 1,   ″simulationId″: 1,   ″pricingDt″: “01/01/2020”,  ″simulationInputs″:[{         “factorName”: ″VIX″,        “rangeStart”: −3544,         “rangeEnd”: 5513       }, {        “factorName”: ″SP500″,         “rangeStart”: −4648,        “rangeEnd”: 2947}    ],   ″businessCycleInputs″: [{         cycleName: ″Late″,          percentage: 100       }, {         cycleName: ″Recession″,          percentage: 0     }]  ... }

Response

201 Content-Type: application/json {  ″summary″: {       “risk”: 234.42.      “avg5Percentle”: −202.09    },  “marketReturns”:[ {      ″marketId″: 959,       ″bucketId″: 4,       ″marketReturn″:−434.16     That'}, {       ″marketId″: 2527,       ″bucketId″: 6,      ″marketReturn″: −252.16     },      ...   ] }

A visualization of the expected portfolio return metrics for theportfolio and/or of the expected security return metrics for theconstituent securities of the portfolio for the market scenarios toutilize may be generated at 2749. In one implementation, user interfacewidgets showing the expected portfolio return metrics and/or theexpected security return metrics may be generated via a portfolioreturns visualization response. See FIGS. 28-30 for examples ofvisualizations that may be generated.

A determination may be made at 2753 whether a business cycle selectioninput was obtained from the user. In one embodiment, the business cycleselection input may be a user interface input from the user with auser-specified business cycle selection. For example, the user mayselect a business cycle (e.g., using a user interface widget to select aspecific business cycle, using a user interface widget to request thatthe MLPO determine the appropriate business cycle (e.g., the businesscycle under which the portfolio has the best or the worst expectedreturn metrics)) to determine how expected portfolio return metrics forthe portfolio and/or for the constituent securities of the portfoliowould change given occurrence of the business cycle (e.g., during theinvestment time period). In another example, the user may selectmultiple business cycles, and an associated weight (e.g., probability ofoccurrence) for each business cycle, to determine how expected portfolioreturn metrics for the portfolio and/or for the constituent securitiesof the portfolio would change given business cycle expectations (e.g.,during the investment time period).

If a business cycle selection input was obtained, the specified set ofbusiness cycles and/or associated business cycle weights may bedetermined at 2755. In one implementation, the set of business cyclesand/or the associated business cycle weights may be specified in avisualization business cycle customization input, and the visualizationbusiness cycle customization input may be parsed (e.g., using PHPcommands) to determine the specified set of business cycles and/or theassociated business cycle weights (e.g., based on the values of thebusiness_cycle_identifier and/or business_cycle_weight fields).

A determination may be made at 2757 whether there remain business cyclesto process. In one implementation, each of the specified business cyclesmay be processed. If there remain business cycles to process, the nextbusiness cycle may be selected for processing at 2759.

The market scenarios to utilize may be filtered based on the selectedbusiness cycle at 2761. In one embodiment, the market scenarios toutilize may be filtered to the subset of market scenarios that areassociated with the selected business cycle. In one implementation, eachmarket scenario to utilize may be associated with a business cycleidentifier (e.g., indicating a business cycle during which a simulatedmarket scenario would have occurred), and market scenarios to utilizewhose business cycle identifiers do not match the business cycleidentifier of the selected business cycle may be filtered out. Inanother embodiment, the market scenarios to utilize also may be filteredbased on specified customized market factors (e.g., as discussed withregard to FIG. 21).

Expected security return metrics for the portfolio securities for thefiltered market scenarios may be calculated at 2765. In oneimplementation, the expected security return metrics for eachconstituent security of the portfolio for the selected business cyclemay be determined by iterating through the filtered market scenarios andcalculating the expected security return metrics based on the expectedreturns (e.g., cached) for the filtered market scenarios. For example,the expected return for a constituent security (e.g., MSFT) of theportfolio for the filtered market scenarios may be determined via aMySQL database command similar to the following:

SELECT AVG(linkedScenarioSecurityExpectedReturn) FROM ExpectedReturnsWHERE securityID = “MSFT” AND linkedSimulationID = ID_sim_1 AND linkedScenarioID IN (ID_scenario_1, ID_scenario_2, ...);

Expected portfolio return metrics for the portfolio for the filteredmarket scenarios may be calculated at 2769. In various implementations,the expected portfolio return metrics for the portfolio for the selectedbusiness cycle may be calculated using a weighted average (e.g.,weighted based on the portfolio securities weights) of the expectedsecurity returns and/or of the calculated expected security returnmetrics for the constituent securities of the portfolio (e.g., via theAPI) for the selected business cycle.

Once the specified business cycles have been processed, weightedexpected security return metrics for the portfolio securities for thespecified business cycles may be calculated at 2773. For example, theweighted expected security return metrics for a security may include thesecurity's weighted expected return, worst returns, return volatility,frequency vs. returns data, and/or the like. In various implementations,the weighted expected security return metrics for a constituent securityfor the specified business cycles may be calculated using a weightedaverage (e.g., weighted based on the associated business cycle weights)of the expected security returns for the constituent security for eachof the specified business cycles and/or of the calculated expectedsecurity return metrics for the constituent security for each of thespecified business cycles.

Weighted expected portfolio return metrics for the portfolio for thespecified business cycles may be calculated at 2777. For example, theweighted expected portfolio return metrics for a portfolio may includethe portfolio's weighted expected return, worst returns, returnvolatility, frequency vs. returns data, and/or the like. In variousimplementations, the weighted expected portfolio return metrics for theportfolio for the specified business cycles may be calculated using aweighted average (e.g., weighted based on the portfolio securitiesweights) of the calculated weighted expected security return metrics forthe constituent securities of the portfolio and/or using a weightedaverage (e.g., weighted based on the associated business cycle weights)of the calculated expected portfolio return metrics for the portfoliofor each of the specified business cycles (e.g., via the API).

A visualization of the weighted expected portfolio return metrics forthe portfolio and/or of the weighted expected security return metricsfor the constituent securities of the portfolio for the specifiedbusiness cycles may be generated at 2781. In one implementation, userinterface widgets showing the weighted expected portfolio return metricsand/or the weighted expected security return metrics may be generated(e.g., via a portfolio returns visualization response, via avisualization business cycle customization output). See FIGS. 28-30 forexamples of visualizations that may be generated.

A determination may be made at 2785 whether a business cycle weightselection input was obtained from the user (e.g., via a visualizationbusiness cycle customization input). In one embodiment, the businesscycle weight selection input may be a user interface input from the userwith user-specified business cycle weights for the specified businesscycles. If a business cycle weight selection input was obtained, thespecified business cycle weights for the specified business cycles maybe updated at 2789. In one implementation, the visualization businesscycle customization input may be parsed (e.g., using PHP commands) todetermine the updated business cycle weights (e.g., based on the valuesof the business_cycle_weight fields). A determination may be made at2793 whether the expected portfolio return metrics for the portfolio foreach of the specified business cycles and/or the expected securityreturn metrics for the constituent securities of the portfolio for eachof the specified business cycles are cached (e.g., from a previouscalculation that used different business cycle weights for the specifiedbusiness cycles). If cached, an updated visualization of the weightedexpected portfolio return metrics for the portfolio and/or of theweighted expected security return metrics for the constituent securitiesof the portfolio for the specified business cycles may be generated asdiscussed with regard to 2773-2781. If not cached, an updatedvisualization of the weighted expected portfolio return metrics for theportfolio and/or of the weighted expected security return metrics forthe constituent securities of the portfolio for the specified businesscycles may be generated as discussed with regard to 2757-2781.

FIG. 28 shows a screenshot illustrating user interface(s) of the MLPO.In FIG. 28, an exemplary user interface (e.g., for a mobile device, fora website) for generating a portfolio returns visualization for aportfolio is illustrated. Screen 2801 shows that a user may utilize abusiness cycle tab 2803 to specify business cycle settings. The user mayutilize business cycle selection widgets 2805A-B to specify businesscycles to utilize. For example, business cycle selection widget 2805Ashows some exemplary business cycles that may be selected by the user.The user may utilize business cycle weight selection widgets 2810A-B tospecify business cycle weights to utilize. For example, the user mayspecify that a portfolio returns visualization should be generated basedon an expectation that the Late business cycle (e.g., selected usingbusiness cycle selection widget 2805A) is going to occur with 100%probability (e.g., selected using business cycle weight selection widget2810A). The user may utilize a positioning widget 2815 to request thatthe MLPO determine the appropriate business cycle. For example, the usermay specify that a portfolio returns visualization should be generatedfor the business cycle under which the portfolio has the best expectedreturns (e.g., Late business cycle).

Screen 2801 shows that the user may utilize a returns distributionwidget 2835 to view the returns distribution of the portfolio under theoriginal business cycle settings. The user may utilize a portfoliosecurities weights widget 2840 to view and/or modify portfoliosecurities weights of individual portfolio securities of the portfoliounder the original business cycle settings. The user may utilize aportfolio securities returns widget 2845 to view expected returns ofindividual portfolio securities of the portfolio under the originalbusiness cycle settings.

FIG. 29 shows a screenshot illustrating user interface(s) of the MLPO.In FIG. 29, an exemplary user interface (e.g., for a mobile device, fora website) for generating a portfolio returns visualization for aportfolio is illustrated. Screen 2901 shows that when the user modifiesthe business cycle settings an updated visualization showing how theexpected portfolio return metrics for the portfolio and/or the expectedsecurity return metrics for the constituent securities of the portfoliohave been affected may be generated. For example, the user may specifythat the updated portfolio returns visualization should be generatedbased on an expectation (e.g., a customization) that the Late businesscycle (e.g., selected using business cycle selection widget 2905A) isgoing to occur with 85% probability (e.g., selected using business cycleweight selection widget 2910A) and the Recession business cycle (e.g.,selected using business cycle selection widget 2905B) is going to occurwith 15% probability (e.g., selected using business cycle weightselection widget 2910B). The updated visualization shows that the usermay utilize a drawdown widget 2925 to view the expected loss (e.g.,−1.30%) at the worst CVaR percentile outcomes for the portfolio underthe customized business cycle settings, the expected loss (e.g., −0.99%)at the worst CVaR percentile outcomes for the portfolio under theoriginal business cycle settings, and the difference in the expectedloss at the worst CVaR percentile outcomes (e.g., −0.31) between the twobusiness cycle settings. The updated visualization shows that the usermay utilize a return volatility widget 2930 to view the returnvolatility (e.g., 0.55%) for the portfolio under the customized businesscycle settings, the return volatility (e.g., 0.40%) for the portfoliounder the original business cycle settings, and the difference in theexpected return volatility (e.g., 0.15%) between the two business cyclesettings. The updated visualization shows that the user may utilize areturns distribution widget 2935 to view the returns distribution forthe portfolio under the customized business cycle settings, the returnsdistribution for the portfolio under the original business cyclesettings, and the difference in the expected returns distributionbetween the two business cycle settings. The user may utilize aportfolio securities weights widget 2940 to view and/or modify portfoliosecurities weights of individual portfolio securities of the portfoliounder the customized business cycle settings. The user may utilize aportfolio securities returns widget 2945 to view expected returns ofindividual portfolio securities of the portfolio under the customizedbusiness cycle settings. The user may utilize an optimize widget 2950 todetermine an optimized portfolio under the customized business cyclesettings (e.g., determined based on the updated weighted expectedsecurity returns for the constituent securities of the portfolio). Theuser may utilize an execute widget 2955 to initiate the execution oftradeable buy and/or sell transactions utilized to create the optimizedportfolio under the customized business cycle settings.

FIG. 30 shows a screenshot illustrating user interface(s) of the MLPO.In FIG. 30, an exemplary user interface (e.g., for a mobile device, fora website) for generating a portfolio returns visualization for aportfolio is illustrated. Screen 3001 shows that the user may utilize apositioning widget 3015 to request that the MLPO determine theappropriate business cycle. For example, the user may specify that aportfolio returns visualization should be generated for the businesscycle (e.g., a customization) under which the portfolio has the worstexpected returns (e.g., Early business cycle (e.g., as shown by businesscycle selection widgets 3005A-B) with 100% probability (e.g., as shownby business cycle weight selection widgets 3010A-B)). The updatedvisualization shows that the user may utilize a drawdown widget 3025 toview the expected loss (e.g., −1.19%) at the worst CVaR percentileoutcomes for the portfolio under the customized business cycle settings,the expected loss (e.g., −0.99%) at the worst CVaR percentile outcomesfor the portfolio under the original business cycle settings, and thedifference in the expected loss at the worst CVaR percentile outcomes(e.g., −0.20) between the two business cycle settings. The updatedvisualization shows that the user may utilize a return volatility widget3030 to view the return volatility (e.g., 0.45%) for the portfolio underthe customized business cycle settings, the return volatility (e.g.,0.40%) for the portfolio under the original business cycle settings, andthe difference in the expected return volatility (e.g., 0.05%) betweenthe two business cycle settings. The updated visualization shows thatthe user may utilize a returns distribution widget 3035 to view thereturns distribution for the portfolio under the customized businesscycle settings, the returns distribution for the portfolio under theoriginal business cycle settings, and the difference in the expectedreturns distribution between the two business cycle settings. The usermay utilize a portfolio securities weights widget 3040 to view and/ormodify portfolio securities weights of individual portfolio securitiesof the portfolio under the customized business cycle settings. The usermay utilize a portfolio securities returns widget 3045 to view expectedreturns of individual portfolio securities of the portfolio under thecustomized business cycle settings.

FIG. 34 shows a datagraph illustrating data flow(s) for the MLPO. InFIG. 34, a client 3402 (e.g., of a user) may send a portfolio returnsvisualization request 3421 to an application server 3406 to facilitategenerating a portfolio returns visualization (e.g., based on customizedmarket factors as discussed with regard to FIG. 20, based on specifiedbusiness cycle settings as discussed with regard to FIG. 26, forconstructing an optimized bond ladder portfolio as discussed with regardto FIG. 37). For example, the client may be a desktop, a laptop, atablet, a smartphone, a smartwatch, and/or the like that is executing aclient application. In one implementation, the portfolio returnsvisualization request may include data such as a request identifier, auser identifier, a predefined scenario identifier, business cyclesettings, a simulation model, a pricing date, a portfolio identifier,investment securities settings, and/or the like. In one embodiment, theclient may provide the following example portfolio returns visualizationrequest, substantially in the form of a (Secure) Hypertext TransferProtocol (“HTTP(S)”) POST message including eXtensible Markup Language(“XML”) formatted data, as provided below:

POST /portfolio_returns_visualization_request.php HTTP/1.1 Host:www.server.com Content-Type: Application/XML Content-Length: 667 <?XMLversion = “1.0” encoding = “UTF-8”?><portfolio_returns_visualization_request> <request_identifier>ID_request_51</request_identifier> <user_identifier>ID_user_1</user_identifier> <simulation_model>ID_neural_network_simula- tion_model_1Y</simulation_model> <pricing_date>2020-04-17</pricing_date> <portfolio_identifier>ID_portfolio_1</portfolio_identifier>  ...</portfolio_returns_visualization_request>

A portfolio returns visualizing (PRV) component 3425 may utilize dataprovided in the portfolio returns visualization request to generate aportfolio return metrics visualization based on asset return metricsprovided by a database calculation engine. In some embodiments, the PRVcomponent may be an optimized version of the SPRV component (e.g.,discussed with regard to FIG. 21), BPRV component (e.g., discussed withregard to FIG. 27), and/or the like components (e.g., a component usedto implement a bond ladder construction process discussed with regard toFIG. 48) that utilizes the database calculation engine for improvedperformance. See FIG. 35 for additional details regarding the PRVcomponent.

The application server 3406 may send an asset return metrics calculationrequest 3429 to a database server 3410 to obtain asset return metricsfor securities in the portfolio for simulated scenarios corresponding tothe specified simulation (e.g., with a simulation identifier determinedbased on the specified pricing date and/or simulation model). In oneimplementation, the asset return metrics calculation request may includedata such as a request identifier, asset return metrics to retrievespecification, and/or the like. In one embodiment, the applicationserver may provide the following example asset return metricscalculation request, substantially in the form of a HTTP(S) POST messageincluding XML-formatted data, as provided below:

POST /asset_return_metrics_calculation_request.php HTTP/1.1 Host:www.server.com Content-Type: Application/XML Content-Length: 667 <?XMLversion = “1.0” encoding = “UTF-8”?><asset_return_metrics_calculation_request> <request_identifier>ID_request_52</request_identifier> <securities>MSFT, AAPL, ...</securities> <simulation_identifier>ID_sim_1</simulation_identifier> <pricing_date>2020-04-17</pricing_date> <requested_asset_return_metrics>   ID_METRIC_EXPECTED_RETURN,ID_METRIC_CVAR  </requested_asset_return_metrics></asset_return_metrics_calculation_request>

An asset return metrics calculating (ARMC) component 3433 may utilizedata provided in the asset return metrics calculation request tocalculate asset return metrics for securities in the portfolio. See FIG.36 for additional details regarding the ARMC component.

The database server 3410 may send an asset return metrics calculationresponse 3437 to the application server 3406 with the requested assetreturn metrics data. In one implementation, the asset return metricscalculation response may include data such as a response identifier, therequested asset return metrics data, and/or the like. In one embodiment,the database server may provide the following example asset returnmetrics calculation response, substantially in the form of a HTTP(S)POST message including XML-formatted data, as provided below:

POST /asset_return_metrics_calculation_response.php HTTP/1.1 Host:www.server.com Content-Type: Application/XML Content-Length: 667 <?XMLversion = “1.0” encoding = “UTF-8”?><asset_return_metrics_calculation_response> <response_identifier>ID_response_52</response_identifier> <asset_simulation_wide_table_data>   <record>   <asset_id>IBM</asset_id>    <pricing_date>2020-04-17</pricing_date>   <simulation_identifier>ID_sim_1</simulation_identifier>   <returns>354,353,369,...</returns>   </record>   <record>   <asset_id>AAPL</asset_id>    <pricing_date>2020-04-17</pricing_date>   <simulation_identifier>ID_sim_1</simulation_identifier>   <returns>384,430,276,...</returns>   </record>   ... </asset_simulation_wide_table_data>  <asset_measure_table_data>  <record>    <asset_id>IBM</asset_id>   <pricing_date>2020-04-17</pricing_date>   <simulation_identifier>ID_sim_1</simulation_identifier>   <scenario_identifier>ID_scenario_1</scenario_identifier>   <metric_identifier>ID_METRIC_EXPECTED_RE- TURN</metric_identifier>   <metric_value>354</metric_value>   </record>   <record>   <asset_id>IBM</asset_id>    <pricing_date>2020-04-17</pricing_date>   <simulation_identifier>ID_sim_1</simulation_identifier>   <scenario_identifier>ID_scenario_2</scenario_identifier>   <metric_identifier>ID_METRIC_EXPECTED_RE- TURN</metric_identifier>   <metric_value>353</metric_value>   </record>   ...   <record>   <asset_id>IBM</asset_id>    <pricing_date>2020-04-17</pricing_date>   <simulation_identifier>ID_sim_1</simulation_identifier>   <scenario_identifier>ID_scenario_1</scenario_identifier>   <metric_identifier>ID_METRIC_CVAR</metric_identifier>   <metric_value>−8.05%</metric_value>   </record>   <record>   <asset_id>IBM</asset_id>    <pricing_date>2020-04-17</pricing_date>   <simulation_identifier>ID_sim_1</simulation_identifier>   <scenario_identifier>ID_scenario_2</scenario_identifier>   <metric_identifier>ID_METRIC_CVAR</metric_identifier>   <metric_value>−9.15%</metric_value>   </record>   ...   <record>   <asset_id>AAPL</asset_id>    <pricing_date>2020-04-17</pricing_date>   <simulation_identifier>ID_sim_1</simulation_identifier>   <scenario_identifier>ID_scenario_1</scenario_identifier>   <metric_identifier>ID_METRIC_EXPECTED_RE- TURN</metric_identifier>   <metric_value>384</metric_value>   </record>   <record>   <asset_id>AAPL</asset_id>    <pricing_date>2020-04-17</pricing_date>   <simulation_identifier>ID_sim_1</simulation_identifier>   <scenario_identifier>ID_scenario_2</scenario_identifier>   <metric_identifier>ID_METRIC_EXPECTED_RE- TURN</metric_identifier>   <metric_value>430</metric_value>   </record>   ...   <record>   <asset_id>AAPL</asset_id>    <pricing_date>2020-04-17</pricing_date>   <simulation_identifier>ID_sim_1</simulation_identifier>   <scenario_identifier>ID_scenario_1</scenario_identifier>   <metric_identifier>ID_METRIC_CVAR</metric_identifier>   <metric_value>−10.05%</metric_value>   </record>   <record>   <asset_id>AAPL</asset_id>    <pricing_date>2020-04-17</pricing_date>   <simulation_identifier>ID_sim_1</simulation_identifier>   <scenario_identifier>ID_scenario_2</scenario_identifier>   <metric_identifier>ID_METRIC_CVAR</metric_identifier>   <metric_value>−7.15%</metric_value>   </record>   ... </asset_measure_table_data></asset_return_metrics_calculation_response>

The application server 3406 may send a portfolio returns visualizationresponse 3441 to the client 3402 to provide a visualization of portfolioreturn metrics for the specified portfolio. In one implementation, theportfolio returns visualization response may include data such as aresponse identifier, visualization data, and/or the like. In oneembodiment, the application server may provide the following exampleportfolio returns visualization response, substantially in the form of aHTTP(S) POST message including XML-formatted data, as provided below:

POST /portfolio_returns_visualization_response.php HTTP/1.1 Host:www.server.com Content-Type: Application/XML Content-Length: 667 <?XMLversion = “1.0” encoding = “UTF-8”?><portfolio_returns_visualization_response> <response_identifier>ID_response_51</response_identifier> <visualization_data>   portfolio return metrics data (e.g., constituentsecurities' and/or   portfolio's returns, worst returns, returnvolatility, frequency vs.   returns data)  </visualization_data></portfolio_returns_visualization_response>

FIG. 35 shows a logic flow illustrating embodiments of a portfolioreturns visualizing (PRV) component for the MLPO. In FIG. 35, aportfolio returns visualization request may be obtained at 3501. Forexample, the portfolio returns visualization request may be obtained asa result of a user requesting generation of a portfolio returnsvisualization. Market scenarios to utilize for generating the portfolioreturns visualization may be determined at 3505. In one embodiment, themarket scenarios to utilize may be determined based on the simulationmodel (e.g., for a specified pricing date) and/or time period lengthselected by the user. In another embodiment, the market scenarios toutilize may be determined based on filters applied to simulated marketscenarios. In one implementation, the portfolio returns visualizationrequest may be parsed (e.g., using PHP commands) to determine the marketscenarios to utilize (e.g., based on the values of the simulation_modeland/or pricing_date fields). For example, the selected simulation modeland/or pricing date may be used to determine a simulation identifier(e.g., ID_sim_1) of the corresponding simulation (e.g., a set ofsimulated market scenarios).

Portfolio securities of a portfolio may be determined at 3509 andportfolio securities weights for the portfolio securities may bedetermined at 3513. In one embodiment, the portfolio securities and/orthe corresponding portfolio securities weights may be retrieved from adatabase (e.g., based on a portfolio identifier). In one implementation,the portfolio returns visualization request may be parsed (e.g., usingPHP commands) to determine the portfolio identifier (e.g., based on thevalue of the portfolio_identifier field). In another embodiment, theportfolio securities and/or the corresponding portfolio securitiesweights may be specified by the user (e.g., via a set of securitiesuniverse widgets as discussed with regard to FIG. 10, via a set ofsecurity selection widgets as discussed with regard to FIG. 41). In oneimplementation, the portfolio returns visualization request may beparsed (e.g., using PHP commands) to determine the specified portfoliosecurities and/or the corresponding portfolio securities weights. Inanother embodiment, the portfolio securities and/or the correspondingportfolio securities weights may be determined based on an optimization.In one implementation, the portfolio securities and/or the correspondingportfolio securities weights may be determined as discussed with regardto the PC component. In another implementation, the portfolio securitiesand/or the corresponding portfolio securities weights may be determinedas discussed with regard to FIG. 48.

Asset return metrics data for the portfolio securities may be obtainedvia the ARMC component at 3517. In one embodiment, an application (e.g.,executed by an application server) may be configured to generate aportfolio returns visualization comprising a set of visualization returnmetrics, and the asset return metrics data utilized to calculate the setof visualization return metrics may be obtained using the databasecalculation engine (e.g., via an asset return metrics calculationrequest). In one implementation, asset simulation wide table data (e.g.,utilized for calculating expected portfolio return metrics for theportfolio) and/or asset measure table data (e.g., utilized forcalculating expected security return metrics for the constituentsecurities of the portfolio) may be obtained. See 706 in FIG. 7C for anexample of asset simulation wide table data. See 710 in FIG. 7C for anexample of asset measure table data.

A determination may be made at 3521 whether there remain visualizationreturn metrics to determine. In one implementation, each of thevisualization return metrics in the set of visualization return metricsmay be determined. If there remain visualization return metrics todetermine, the next visualization return metric may be selected forprocessing at 3525.

A determination may be made at 3529 regarding the type of the selectedvisualization return metric. In one embodiment, a visualization returnmetric may be an expected portfolio return metric calculated for aportfolio. In another embodiment, a visualization return metric may bean expected security return metric calculated for a security.

If the selected visualization return metric type is portfolio, theselected expected portfolio return metric for the portfolio may bedetermined using the asset simulation wide table data at 3533. Forexample, expected portfolio return metrics for a portfolio may includethe portfolio's expected return, worst returns, return volatility,frequency vs. returns data, and/or the like. In various implementations,the selected expected portfolio return metric for the portfolio may becalculated using a weighted average (e.g., weighted based on theportfolio securities weights) of expected security returns and/or ofdetermined expected security return metrics for the constituentsecurities of the portfolio using the asset simulation wide table data.For example, the following API may be utilized to determine expectedportfolio return metrics, in the set of visualization return metrics,for the portfolio for the market scenarios to utilize:

Post API/RunAnalysis

-   -   This API facilitates generating portfolio return metrics        visualization for a specified portfolio (e.g., list of        securities). The portfolio return metrics calculation results        are included in the Summary object returned by the API.    -   The API returns HTTP/1.1 status code 201 if the request is        successful. It returns 500 Internal Server Error if there is an        exception.

Input Parameter Details

Attribute name Mandatory Default Description/Rule securityInputs YSpecify the initial investment simulationId Y 0 Taxable = 1, Tax-Exempt= 0 simulationInputs Y List of factor min and max range for filtering ofscenarios businessCycleInputs N List of business cycle inputs andassociated percentages. (e.g., Late Cycle 50% and Recession 50%)pricingDt Y Current Pricing Date for which simulation data is available

Request

POST API/runAnalysis Content-type: application/json{″securityInputs″:[{″cusip″:″806551EB9″, ″qty″:9000,″price″:101.11},              {″cusip″:″806640VU9″,              ″qty″:14000,″price″:100}], ″simulationId″:6,″scenarioInputs″:[{  ″id″:1,  ″type″:1, ″simulationInputs″:[{″factorName″:″VIX″,″rangeStart″:−4588,″range- End″:6796},  {″factorName″:″SP500″,″rangeStart″:−5161,″rangeEnd″:4082}], ″businessCycleInputs″:[ ] }, {  ″id″:2,  ″type″:1, ″simulationInputs″:[ ],  ″businessCycleInputs″:[{cycleName: ″Late″,percentage: 100},  {cycleName:   ″Recession″, percentage: 0}] },...],“pricingDt”:”02/26/2020”, ″logger″:true }

Response

201 Content-Type: application/json {  ″summary″: [{   “id”:1,   “risk”:234.42,   “mean”: 255,   “cvar”: −202.09,   “5per”: −172,   “25per”:−74,   “50per”: −24,   “75per”: 154,   “95per”: 34,  },{   “Id” :2,  “risk”: 258.30,   “mean”: 267,   “cvar”: −256.09,   “5per”: −176,  “25per”: −74,   “50per”: −21,   “75per”: 165,   “95per”: 38,  },...], “marketReturns”:[ {   “marketId”: 959,   “bucketId”: 4,  “marketReturn”: −434.16   }, {   “marketId”: 2527,   “bucketId”: 6,  “marketReturn”: −252.16   },   ...  ] }

If the selected visualization return metric type is security, theselected expected security return metric for the portfolio securities ofthe portfolio may be determined using the asset measure table data at3537. For example, expected security return metrics for a security mayinclude the security's expected return, worst returns, returnvolatility, frequency vs. returns data, and/or the like. In variousimplementations, the selected expected security return metric for eachsecurity may be determined (e.g., retrieved, calculated) using the assetmeasure table data. For example, the following API may be utilized todetermine expected security return metrics, in the set of visualizationreturn metrics, for the portfolio securities of the portfolio for themarket scenarios to utilize:

Operation Operation on Entities Type End Point Description Run Bond POSTapi/runBondLadderOptimizer Gets the bond Ladder ladder based onOptimizer rule-based optimization. The API automatically calls theavailable bonds API to get available bonds based on filter criteria. Itthen constructs the bond ladder.

Post API/RunBondLadderOptimizer

This API facilitates generating portfolio returns visualization. ThisAPI returns the bond ladder based on filter specified as part of theinput. The API automatically calls the available bonds, applies thefilter and then returns bond ladder based on rule-based optimization.

The API returns HTTP/1.1 status code 201 if the request is successful.It returns 500 Internal Server Error if there is an exception.

Input Parameter Details

Attribute name Mandatory Default Description/Rule startInvestment Y 0Specify the initial investment startYear Y Integer between 1 and 50endYear Y Integer between 1 and 50. Should be greater than startYeartaxStatus N 1 Taxable = 1, Tax-Exempt = 0 composition N filter Y FALSESet to TRUE if filter should be applied. creditquality N Mandatory ifFilter is set to TRUE federalTax N stateTax N surTax N step Y 1 Integervalue to specify the Yield Range: 1 = Full Market (1st to 4th Quartiles)2 = Standard (2nd and 3rd Quartile) 3 = Conservative (1st and 2ndQuartile) 4 = Aggressive (3rd and 4th Quartile) diversification Y 0.03Integer value to specify the Diversification (i.e., max allowedallocation based on the percentage of total market value of theportfolio): 0.03 = High (Max Position size = 3%) 0.05 = Medium (MaxPosition size = 5%) 0.07 = Low (Max Position size = 7%) 1 = No Limit onPosition size riskAdjusted N FALSE FALSE = Maximize Yield TRUE = RiskAdjusted Yield

Request

POST API/runBondLadderOptimizer Content-type: application/json { ″startInvestment″: 1000000,  ″startYear″: 1,  ″endYear″: 15, ″taxStatus″: 1,  ″composition″: 1,  ″filter″: true,  ″creditquality″:″BB+″,  ″federalTax″: 37,  ″stateTax″: 5.1,  ″surTax″: 3.8,  ″step″: 4, ″diversification″: 0.03,  “riskAdjusted”:true }

Response

201 Content-Type: application/json {  ″yield″: 4.515983619734928, “proposed”:[ {   ″fmrCusip″: ″AEG778000″,   ″description″: ″ALPHABETINC 3.625% 05/19/21″,   ″price″: 103.04,   ″yearsToMaturity″: 2,  ″staticYield″: 1.774,   ″minDenomination″: 2000,   ″minIncrement″:1000,   ″rating″: ″AA″,   ″ratingGrp″: 0,   ″tradableQty″: 40,  ″kdp_1yr″: 0.011852,   ″kdp_2yr″: 0.076579,   ″kdp_3yr″: 0.117952,  ″kdp_4yr″: 0.134964,   ″kdp_5yr″: 0.177211,   ″kdp_7yr″: 0.267062,  ″kdp_10yr″: 0.267116,   ″ratingsIndex″: 2,   ...  }...], “bondLadderList”:[ {   ″marketValue″: 67000,   ″priceChange″:45159.83619734928,   ″defaultValue″: 0,   ″yearsToMaturity″: 11,  ″securities″: [ ]}...],  “ratingsList”:[ {   ″rating″: ″AA″,  ″weight″: 0.0028821924148899635  }...],  “logs”:[...] }

A visualization of the expected portfolio return metrics for theportfolio and/or of the expected security return metrics for theconstituent securities of the portfolio for the market scenarios toutilize may be generated at 3541. In one implementation, user interfacewidgets showing the expected portfolio return metrics and/or theexpected security return metrics may be generated via a portfolioreturns visualization response. See FIGS. 22-25, 28-30, and 41-47 forexamples of visualizations that may be generated.

FIG. 36 shows a logic flow illustrating embodiments of an asset returnmetrics calculating (ARMC) component for the MLPO. In FIG. 36, an assetreturn metrics calculation request may be obtained at 3601. For example,the asset return metrics calculation request may be obtained as a resultof an application requesting calculation of asset return metrics data.

Assets to analyze may be determined at 3605. In one embodiment, assetreturn metrics data may be calculated for the determined assets. In oneimplementation, the asset return metrics calculation request may beparsed (e.g., using PHP commands) to determine the assets (e.g., a setof portfolio securities) to analyze (e.g., based on the value of thesecurities field). In another implementation, the assets (e.g., auniverse of securities (e.g., bonds)) to analyze may be determined(e.g., to precalculate and/or cache asset return metrics data) based ona configuration setting.

A simulation identifier to utilize may be determined at 3609. In oneembodiment, the simulation identifier may identify a set of simulatedmarket scenarios to utilize to calculate asset return metrics data. SeeFIGS. 2A-B and FIG. 4 for additional details regarding the MLSSPcomponent, which may be used to generate simulated market scenarios. Inone implementation, the asset return metrics calculation request may beparsed (e.g., using PHP commands) to determine the simulation identifier(e.g., based on the value of the simulation_identifier field).

A pricing date to utilize may be determined at 3613. In one embodiment,the pricing date may represent the date for which analytics (e.g., KeyRate Durations (KRD), Option Adjusted Spread, Muni KRDs, etc.) for theassets are available and/or when asset simulations are calculated. Inone implementation, the asset return metrics calculation request may beparsed (e.g., using PHP commands) to determine the pricing date (e.g.,based on the value of the pricing_date field). In anotherimplementation, the latest available pricing date may be utilized.

Assets may be filtered based on available factor exposures at 3617. Inone embodiment, such filtering is a data reduction technique utilized toreduce the number of records used during calculations thus loweringprocessing time. In one implementation, the factor exposure table (e.g.,factor_expo table in FIG. 40) may comprise data calculated for assetsthat have analytics available, while the assets table (e.g., asset tablein FIG. 40) may comprise data for the available assets (e.g., assets inthe universe of securities, assets in the set of portfolio securities).This filtering ensures that those assets for which factor exposures areavailable are processed. In various implementations, assets may beprocessed using sessions (e.g., as discussed with regard to 3633) witheach session targeting specific range of assets to be processed. Forexample, if the assets are processed in 4 sessions, the first sessionmay target the first 250K assets, the second session may target assetsfrom 250K to 500K, and so on. Each session may be configured to haveaccess to its own set of global temporary tables that is used to storeinformation related to the assets the respective session is processing(e.g., data may not be shared between sessions). Reducing the assets tothose assets that are processed by a session and storing in a globaltemporary table for the session ensures that big table joins areeliminated during the asset return calculation process. In someimplementations, the asset return calculation process may be rerunnable,and may be configured to ignores the assets that are already processedin the previous run. For example, the assets may be filtered based onavailable factor exposures via an Oracle RDS on Cloud database commandsimilar to the following:

-   -   In the query below, the factor exposure is reduced to the assets        being targeted in the session and further reduced to ignore        assets that are already processed if the asset return        calculation process is rerun.

INSERT INTO <db-schema>.global_asset_list SELECT DISTINCT fe.asset_idFROM  (SELECT DISTINCT asset_id FROM <db-schema>.factor_expo  WHEREpricing_dt = lc_truncatedPricingDate  ORDER BY asset_id offset p_offsetROWS  FETCH NEXT p_rangeVal ROWS ONLY) fe LEFT OUTER JOIN  (SELECTDISTINCT asset_id FROM <db-schema>.asset_sim_wide am  WHEREam.pricing_dt = lc_truncatedPricingDate) asw ON (fe.asset_id =asw.asset_id) WHERE asw.asset_id IS NULL;

Factor simulations may be filtered based on the filtered assets at 3621.In one embodiment, such filtering is a data reduction technique utilizedto reduce the number of records used during calculations thus loweringprocessing time. In one implementation, the factor simulations table(e.g., factor_sim table in FIG. 40) may comprise simulated returns formarket factors (e.g., 40+ factors which is around 300K records). Thisfiltering determines a set of market factors to which the filteredassets have exposure (e.g., this reduces the number of factor simulationrecords that are loaded by 50%, to around 150K records, and/or reducesthe JOIN for further processing). In some implementations, a factorsimulation may contain factor simulation data for multiple simulationswith multiple simulation dates. Filtering the table to include targetedsimulation ids reduces the number of records that are utilized forcalculations. Each asset may have exposure to certain factors and usingthe factors that the targeted assets have exposure to can further reducethe size of the factor simulation table that is processed. For example,for 250K assets, the unique factors that these assets have access to maybe 10 instead of 40+ factors for which factor simulations are available.Reducing the factor simulation to include factor simulations for fewerfactors reduce the number of records. Also, storing the data intemporary table instead of using the main table reduces the need tofilter data during calculations. For example, the factor simulations maybe filtered based on the filtered assets via an Oracle RDS on Clouddatabase command similar to the following:

INSERT INTO <db-schema>.mglobal_factor_sim_tmp SELECT * FROM<db-schema>.factor_sim fs WHERE fs.sim_id IN (p_simIdQuarterly,p_simIdBiAnnually, p_simIdYearly) AND fs.factor_id IN ( SELECT DISTINCTfactor_id FROM <db- schema>.factor_expo fe INNER JOIN<db-schema>.global_asset_list gal ON fe.asset_id = gal.asset_id WHEREfe.pricing_dt = lc_truncatedPricingDate )

In some implementations, the factor exposure table and the factorsimulations table may be augmented to integrate the impact of convexityin asset simulation. The convexity metric (e.g., option adjustedconvexity) may be obtained from Sentinel's security_master table. Thefactor exposure table may be augmented by inserting convexity as (e.g.,two) new market factors (e.g., id 80 for non-muni instruments, id 81 formuni instruments). For example, the exposure table may be augmented viaan Oracle RDS on Cloud database command similar to the following:

SELECT cusip as asset_id, 80 as factor_id, 1/2 * security_master.option_adjusted_convexity / 10000 as exposure FROMsecurity_master WHERE product_name != ′Municipal′ UNION ALL SELECT cusipas asset_id, 81 as factor_id, 1/2 * security_master.option_adjusted_convexity / 10000 as exposure FROMsecurity_master WHERE product_name = ′Municipal′

The factor simulations table may be augmented by inserting the square ofthe change in yield (e.g., using the average return of different keyrates as the proxy for the change in yield) as (e.g., two) new marketfactors (e.g., id 80 for Treasury curves, id 81 for muni curves) foreach simulation and each market scenario. For example, the factorsimulations table may be augmented via an Oracle RDS on Cloud databasecommand similar to the following:

/*  Treasury curves 3M, 6M, 1Y, 2Y, 3Y, 5Y, 7Y, 10Y, 20Y, 30Y  Municurves 2Y, 5Y, 10Y, 20Y */ with oac_factor as (  select fs.sim_id,fs.market_id, power(avg(fs.return), 2) as return,  case when f.type =′Treasury Curves′ then 80    when f.type = ′Muni Curves′ then 81  end asfactor_id  from factor_sim fs, factor f  where fs.factor_id = f.id  andfs.factor_id in    (select f.id from factor f where f.type = ′TreasuryCurves′ or      f.type = ′Muni Curves′)  group by fs.sim_id, f.type,fs.market_id  order by fs.market_id ) select distinct fs.sim_id,fs.market_id, fs.bucket_id, oo.factor_id, oo.return from oac_factor oo,factor_sim fs where oo.sim_id=fs.sim_id and oo.market_id=fs.market_idorder by sim_id, market_id

Factor exposures may be filtered based on the filtered assets and/or thepricing date at 3625. In one embodiment, such filtering is a datareduction technique utilized to reduce the number of records used duringcalculations thus lowering processing time. In one implementation, thefactor exposure table may store factor exposures for assets for multiplepricing dates (e.g., for the last three runs/dates). This filteringdetermines a set of factor exposure records for the pricing date (e.g.,for the current pricing date and filters out records for older pricingdates) that are associated with the filtered assets (e.g., assets forwhich factor exposures are available). For example, the factor exposuresmay be filtered based on the filtered assets and/or the pricing date viaan Oracle RDS on Cloud database command similar to the following:

INSERT INTO <db-schema>.mglobal_factor_expo_tmp  SELECT Fe.*  FROM<db-schema>.factor_expo fe  INNER JOIN <db-schema>.global_asset_list gal  ON fe.asset_id = gal.asset_id  WHERE fe.pricing_dt =lc_truncatedPricingDate;

Call and/or put schedules may be filtered based on the filtered assetsat 3629. In one embodiment, such filtering is a data reduction techniqueutilized to reduce the number of records used during calculations thuslowering processing time. In one implementation, the call schedule table(e.g., call_schedule table in FIG. 40) and/or the put schedule table(e.g., put_schedule table in FIG. 40) may comprise call and/or putprices for the available assets (e.g., assets in the universe ofsecurities, assets in the set of portfolio securities). This filteringdetermines a set of call and/or put schedule records that are associatedwith the filtered assets (e.g., assets for which factor exposures areavailable). For example, the call and/or put schedules may be filteredbased on the filtered assets via an Oracle RDS on Cloud database commandsimilar to the following:

-   -   The query below is separated out into two parts. The first part        focuses on getting the call and put price based on different        horizons and call date. The second part focuses on calculating        the call and put returns which will result in defining the lower        cap of the simulated returns.

INSERT /*+APPEND PARALLEL(8) */ INTO<db-schema>.mglobal_call_schedule_tmp SELECTnvl(call_price_1y.cusp_n,put_price_1y.cusp_n) AS cusp_n,call_price_1y.red_price_a c_prc_1y, put_price_1y.red_price_a p_prc_1y,least(nvl(call_price_1y.red_eff_d, ′31-DEC-2099′),nvl(put_price_1y.red_eff_d, ′31-DEC-2099′) ) red_eff_d FROM (SELECT cusp_n, red_eff_d, red_price_a FROM ( SELECT cusp_n, red_eff_d,red_price_a, ROW_NUMBER( ) OVER( PARTITION BY cusp_n ORDER BY red_eff_d) rownumber FROM ( SELECT cusp_n, red_eff_d, red_price_a FROM<db-schema>.call_schedule WHERE red_eff_d > lc_truncatedPricingDate AND( ( red_eff_d − lc_truncatedPricingDate ) / 365 < 1 ) ) ) WHERErownumber = 1 ) call_price_1y FULL OUTER JOIN ( <query put_scheduletable> ) put_price_1y ON call_price_1y.cusp_n = put_price_1y.cusp_n;INSERT /*+ APPEND PARALLEL(8) */ INTO <db-schema>.global_call_put_pricesSELECT /*+ full(asim) full(sm) full(cs) parallel(asim 8) parallel(sm 8)parallel(cs 8) */ b.asset_id asset_id, b.put_price_factor_1y,b.call_price_factor_1y, b.yield_to_worst_rate_factor *LEAST(lv_horizonQuarterly, b.maturity_factor) quarterly_horizon_factor,b.yield_to_worst_rate_factor * LEAST(lv_horizonBiAnnually,b.maturity_factor) biannual_horizon_factor,b.yield_to_worst_rate_factor * LEAST(lv_horizonYearly,b.maturity_factor) yearly_horizon_factor FROM (SELECT sm.cusp_nasset_id, NVL( (cs.p_prc_1y / sm.cls_prc − 1) *lv_callPricePutPriceMultiplicationFactor,−lv_putCallMaxValue)put_price_factor_1y, NVL( (cs.c_prc_1y / sm.cls_prc − 1) *lv_callPricePutPriceMultiplicationFactor, lv_putCallMaxValue)call_price_factor_1y, LEAST( ( (sm.mty_d − lc_truncatedPricingDate ) /365), NVL( ( (cs.red_eff_d −lc_truncatedPricingDate)/ 365),lv_putCallMaxValue) ) maturity_factor, sm.calc_yld_to_wrst_rte * 100yield_to_worst_rate_factor FROM <db-schema>.mglobal_security_master_tmpsm LEFT JOIN <db-schema>.mglobal_call_schedule_tmp cs ON sm.cusp_n =cs.cusp_n) b;

The number of sessions to utilize for calculating asset return metricsdata may be determined at 3633. In one embodiment, asset return metricsdata may be calculated using parallel queries with a specified degree ofparallelism. Accordingly, each parallel query may be processed using anumber of query server processes corresponding to the specified degreeof parallelism. In various implementations, the degree of parallelismfor a parallel query may be specified at the statement level, at thesession level, at the table level, at the index level, and/or the like.For example, a parallel query may specify that 8 query server processesshould be used for processing the parallel query. In one implementation,the number of sessions to utilize may be determined based on availableserver resources to maintain a consistent degree of parallelism bycreating a balance between sessions and parallel query server processes(e.g., threads). For example, for a server having 32 processors (e.g.,CPUs, physical cores, virtual cores), 4 sessions may be utilized (e.g.,determined by dividing the number of available processors by thespecified degree of parallelism). Each session may be utilized forcalculating asset return metrics data as discussed with regard to3637-3693.

An assets range for a session may be determined at 3637. In oneembodiment, an assets range for a session may refer to the set of assetsto be processed by the session. In one implementation, the assets rangefor the session may be determined by dividing the filtered assets basedon the number of sessions. For example, if there are in total 800Kfiltered assets for which asset return metrics data should becalculated, the filtered assets may be divided into 4 sets of assetseach targeting 200K unique assets, and the session may be assigned 1 ofthe 4 sets of assets as the session's session assets.

A determination may be made at 3641 whether there remain session assetsto analyze. In one implementation, each of the session's session assetsmay be analyzed. If there remain session assets to analyze, a batch sizeto utilize may be determined at 3645. In one implementation, the batchsize may be specified in a configuration setting. For example, the batchsize may be configured to be 1000 assets. In another implementation, thebatch size may depend on the number of assets that remain to beanalyzed. For example, if 300 assets remain to be analyzed, then thebatch size may be 300 assets instead of 1000 assets.

A temporary table of session assets of the determined batch size may becreated at 3649. In one implementation, a session assets batch of thedetermined batch size may be selected from the session assets thatremain to be analyzed. For example, the temporary table comprising thesession assets batch may be created via an Oracle RDS on Cloud databasecommand similar to the following:

INSERT INTO <db-schema>.global_asset_id_distinct_tmp  SELECT asset_id FROM <db-schema>.global_asset_list  ORDER BY asset_id ASC offsetlv_startIndex ROWS  FETCH NEXT lv_loopIncrement ROWS ONLY;

A temporary table of factor simulations for the session assets batch maybe created at 3653. In one implementation, the temporary table of factorsimulations may be created by transposing factor simulations to storefactor simulations for simulation ids representing different timehorizons (e.g., this may reduce the number of records in the join asdata related to different simulations are available in columns, makingthe expected returns calculation as discussed with regard to 3661 threetimes faster). For example, the temporary table of factor simulationsfor the session assets batch may be created via an Oracle RDS on Clouddatabase command similar to the following:

INSERT INTO pfmofrdbo.global_factor_sim_tmp  SELECT *  FROM   (SELECTfs2.market_id,    fs2.factor_id,    fs2.sim_id AS sim_id,    fs2.returnAS RETURN   FROM    (SELECT fs.* FROM <db-schema>.mglobal_factor_sim_tmpfs    WHERE fs.factor_id IN     (SELECT DISTINCT factor_id FROM<db-schema>.global_     factor_expo_tmp)    ) fs2   WHERE fs2.sim_id IN(p_simIdQuarterly, p_simIdBiAnnually,   p_simIdYearly)   ) PIVOT(SUM(RETURN) FOR (sim_id) IN (20 AS return_quar-   terly, 21 ASreturn_biannual, 22 return_yearly));

A temporary table of factor exposures for the session assets batch maybe created at 3657. In one implementation, the temporary table of factorexposures may be created by selecting filtered factor exposures for thesession assets batch. For example, the temporary table of factorexposures for the session assets batch may be created via an Oracle RDSon Cloud database command similar to the following:

  INSERT INTO <db-schema>.global_factor_expo_tmp  SELECT fe.*  FROM<db-schema>.mglobal_factor_expo_tmp fe  JOIN<db-schema>.global_asset_id_distinct_tmp age  ON fe.asset_id =age.asset_id  WHERE fe.pricing_dt = lc_truncatedPricingDate;

Expected returns for the session assets batch may be calculated viaparallel execution (e.g., via a parallel query) at 3661. In oneimplementation, the expected returns for the session assets batch may becalculated as the sum product of the factor exposures for the sessionassets batch and the simulated returns of filtered factor simulationsfor the session assets batch. For example, the expected returns for thesession assets batch may be calculated via parallel execution via anOracle RDS on Cloud database command similar to the following:

  SELECT  /*+ full(f) full(e) parallel(f 8) parallel(e 8) */  e.asset_idasset_id,  f.market_id,  SUM(e.exposure * f.return_quarterly)return_quarterly,  SUM(e.exposure * f.return_biannual) return_biannual, SUM(e.exposure * f.return_yearly) return_yearly FROM<db-schema>.global_factor_sim_tmp f JOIN<db-schema>.global_factor_expo_tmp e ON (f.factor_id = e.factor_id)GROUP BY e.asset_id,  f.market_id

The expected returns for the session assets batch may be adjusted basedon call and/or put schedules via parallel execution (e.g., via aparallel query) at 3665. In one implementation, if an asset has anembedded call option redeemable within the investment horizon, thereturn from exercising the call option may be set as the upper bound ofthe simulated asset return, and/or if an asset has an embedded putoption redeemable within the investment horizon, the return fromexercising the put option may be set as the lower bound of the simulatedasset return. For example, the call/put option schedules (e.g.,including redemption dates and prices) may be obtained from Sentinel'scall_schedule/put_schedule tables via an Oracle RDS on Cloud databasecommand similar to the following:

SELECT as1.pricing_dt, as1.sim_id, as1.asset_id, as1.market_id,greatest(least(as1.simulated_return, (cs.next_call_price / sm.current_instrument_price - 1) * 10000), (ps.next_put_price /sm.current_instrument_price - 1) * 10000) FROM asset_sim as1,security_master sm, call_schedule cs, put_schedule ps WHERE as1.asset_id= sm.cusip AND as1.asset_id = cs.cusip AND as1.asset_id = ps.cusip ANDcs.earliest_next_call_date <= as1.investment_horizon ANDps.earliest_next_put_date <= as1.investment_horizonFor example, the expected returns for the session assets batch may beadjusted based on call and/or put schedules via parallel execution viaan Oracle RDS on Cloud database command similar to the following:

SELECT   /*+ full(asim) full(scp) parallel(asim 8) parallel(scp 8) */  asim.asset_id,   asim.market_id,  GREATEST(GREATEST(scp.put_price_factor_3m,  LEAST(asim.return_quarterly, scp.call_price_factor_3m ) ) +scp.quarterly_horizon_factor, −10000) return_quarterly,  GREATEST(GREATEST(scp.put_price_factor_6m,  LEAST(asim.return_biannual, scp.call_price_factor_6m ) ) +scp.biannual_horizon_factor, −10000) return_biannual,  GREATEST(GREATEST(scp.put_price_factor_1y,   LEAST(asim.return_yearly,scp.call_price_factor_1y ) ) + scp.yearly_horizon_factor, −10000)return_yearly  FROM   (SELECT    /*+ full(f) full(e) parallel(f 8)parallel(e 8) */    e.asset_id asset_id,    f.market_id,    ...<complete query from 0391>   ) asim  JOIN<db-schema>.global_call_put_prices scp  ON scp.asset_id = asim.asset_id;

The expected returns for the session assets batch may be transposed intoarray format at 3669. In one embodiment, the wide array format mayfacilitate improved performance when calculating portfolio level returnmetrics. For example, the expected returns for the session assets batchmay be transposed into array format via an Oracle RDS on Cloud databasecommand similar to the following:

-   -   Custom data type asset_sim_return_data_type is used to store an        array of decimal values. Each decimal value is split into two        parts (e.g., X.Y where X represents the CVaR value and Y        represents the market id). Storing both CVaR metric and the        associated market id allows storing data in one variable instead        of two thus saving storage. This also allows parallel execution        of collecting returns in the array format and maintaining the        market ids for which each of the returns are associated with.

SELECT   /*+ full(asim) parallel(asim 8) */   asim.asset_id,  lc_truncatedPricingDate AS pricing_dt,   CAST ( COLLECT(  TO_BINARY_DOUBLE(TRUNC(asim.return_quarterly)+SIGN(asim.return_quarterly)* ((asim.market_id*10) ) +1 )/ 1000000 )) ASASSET_SIM_RETURN_DATA_TYPE) return_quarterly,   CAST ( COLLECT(  TO_BINARY_DOUBLE(TRUNC(asim.return_biannual) +SIGN(asim.return_biannual)* ((asim.market_id*10) +1 )/ 1000000 )) ASASSET_SIM_RETURN_DATA_TYPE) return_biannual,   CAST ( COLLECT(  TO_BINARY_DOUBLE(TRUNC(asim.return_yearly) + SIGN(asim.return_yearly)*((asim.market_id*10) +1 )/ 1000000 ) )AS ASSET_SIM_RETURN_DATA_TYPE)return_yearly  FROM <db-schema>.global_asset_sim_tmp asim  GROUP BYasim.asset_id  ) UNPIVOT (RETURN FOR sim_id IN (return_quarterly AS 20, return_biannual AS 21, return_yearly AS 22)

The transposed expected returns for the session assets batch may bewritten to the asset simulation wide table via parallel execution (e.g.,via a parallel query) at 3673. In one implementation, the assetsimulation wide table (e.g., asset_sim_wide table in FIG. 40) may bewritten to in parallel by query server processes from the utilizedsessions (e.g., by up to 32 query server processes when utilizing 4sessions with degree of parallelism of 8). For example, the transposedexpected returns for the session assets batch may be written to theasset simulation wide table via parallel execution via an Oracle RDS onCloud database command similar to the following:

INSERT INTO <db-schema>.asset_sim_wide  /*+ parallel(8)NO_GATHER_OPTIMIZER_STATISTICS */  SELECT *  FROM   (SELECT    /*+full(asim) parallel(asim 8) */    asim.asset_id,   lc_truncatedPricingDate AS pricing_dt,    CAST ( COLLECT(   TO_BINARY_DOUBLE(TRUNC(asim.return_quarterly)+  ... <complete queryfrom 3669>

A determination may be made at 3677 whether there remain asset returnmetrics to calculate for the session assets batch. In oneimplementation, each of the asset return metrics (e.g., requested assetreturn metrics specified in the asset return metrics calculationrequest, default asset return metrics specified in a configurationsetting) may be calculated. If there remain asset return metrics tocalculate, the next asset return metric may be selected at 3681. Forexample, asset return metrics may include a security's expected return,worst returns (CVaR), return volatility, and/or the like.

The selected asset return metric for the session assets batch may becalculated via parallel execution (e.g., via a parallel query) at 3685.For example, the average of 5% worst returns may be calculated for theCVaR asset return metric. In one implementation, the selected assetreturn metric for the session assets batch may be calculated inaccordance with an applicable formula for the selected asset returnmetric. For example, the selected asset return metric (e.g., CVaR) forthe session assets batch may be calculated via parallel execution via anOracle RDS on Cloud database command similar to the following:

-   -   The query below shows how CVaR measure is calculated in parallel        based on available asset returns for a single horizon. Similar        queries may be run for bi-annual and annual horizons.        lc_truncatedPricingDate holds the pricing date for which the        batch is run, lv_marketCount holds the number of markets used        for simulations and lv_marketPercentageForCvar holds the        percentage value used for calculating the CVaR (e.g., average of        the worst 5% returns).

SELECT   /*+ parallel(8) */   lc_truncatedPricingDate pricing_dt,  asim.asset_id,   p_simIdQuarterly,   ′CVAR′ measure_name,   NULL ASfactor_id,   NULL AS market_id,   AVG(asim.return_quarterly)measure_value  FROM   (SELECT *   FROM    (SELECT asim.asset_id,    asim.return_quarterly,     ROW_NUMBER( ) OVER( PARTITION BYasim.asset_id     ORDER BY asim.return_quarterly ) rk    FROM<db-schema>.global_asset_sim_tmp asim    ) asim   WHERE rk <=lv_marketPercentageForCvar * lv_marketCount   ) asim  GROUP BYasim.asset_id;

The selected asset return metric for the session assets batch may bewritten to the asset measure table via parallel execution (e.g., via aparallel query) at 3689. In one implementation, the asset measure table(e.g., asset_measure table in FIG. 40) may be written to in parallel byquery server processes from the utilized sessions (e.g., by up to 32query server processes when utilizing 4 sessions with degree ofparallelism of 8). For example, the selected asset return metric (e.g.,CVaR) for the session assets batch may be written to the asset measuretable via parallel execution via an Oracle RDS on Cloud database commandsimilar to the following:

  INSERT INTO <db-schema>.asset_measure  /*+ parallel(8)NO_GATHER_OPTIMIZER_STATISTICS */  SELECT   /*+ parallel(8) */  lc_truncatedPricingDate pricing_dt,   asim.asset_id,  p_simIdQuarterly,   ′CVAR′ measure_name,  ... <complete query from3685>

The temporary tables created for the session assets batch may be clearedat 3693. In one embodiment, the temporary tables created for the sessionassets batch may be cleared to reduce temporary storage utilization. Forexample, the temporary tables created for the session assets batch maybe cleared via an Oracle RDS on Cloud database command similar to thefollowing:

EXECUTE IMMEDIATE ′TRUNCATE TABLE<db-schema>.global_asset_id_distinct_tmp DROP STORAGE′ ; EXECUTEIMMEDIATE ′TRUNCATE TABLE <db-schema>.global_factor_expo_tmp DROPSTORAGE′ ; EXECUTE IMMEDIATE ′TRUNCATE TABLE<db-schema>.global_factor_sim_tmp DROP STORAGE′ ; EXECUTE IMMEDIATE′TRUNCATE TABLE <db-schema>.global_asset_sim_tmp DROP STORAGE′ ;

Asset return metrics data from the asset simulation wide table and/orthe asset measure table may be provided to the requesting application at3697. In one implementation, the asset return metrics data may beprovided via an asset return metrics calculation response. In someimplementations, global temporary tables may be cleaned up using DataDefinition Language (DDL) statements for faster execution.

FIG. 37 shows an architecture for the MLPO. In FIG. 37, an embodiment ofhow the database calculation engine 3701 may be utilized to facilitategeneration of a portfolio returns visualization (e.g., for constructingan optimized bond ladder portfolio) is illustrated.

FIG. 38 shows an architecture for the MLPO. In FIG. 38, an embodiment ofhow the factor exposure table may be generated using parallel processing(e.g., via a parallel query) is illustrated. For example, the factorexposure table may be generated via parallel execution via an Oracle RDSon Cloud database command similar to the following:

  INSERT INTO Factor Expo /*+ parallel(8) NO_GATHER_OPTIMIZER_STATISTICS*/ SELECT /*+ full(a) parallel(a 8) */  case b.factor_id   when 50 then-- exposure for muni 2Y   when 55 then -- exposure for muni 5Y   when280 then - dimension reduction using median OAS   ...  end FROMINST_REF_ANALYTICS_TEMP a INNER JOIN SECURITYTYPE_FACTOR_TEMP b ona.product_type = b.product_type

FIG. 39 shows an architecture for the MLPO. In FIG. 39, an embodiment ofan asset return metric calculation process that may be utilized tofacilitate operation of the database calculation engine is illustrated.For example, the asset return metric calculation process may beimplemented via pseudocode similar to the following:

Asset Return Metric Calculation Process Pseudocode GET Input of range ofassets to run for the sessions CLEAR all temporary tables FIND targetassets based on filter criteria/input POPULATE temporary table withfactor sims for target assets POPULATE temporary table with factorexposure for target assets SET no-of-target-assets to total number oftarget assets to be processed WHILE no-of-target-assets > 0  FETCH next1000 assets from target assets  POPULATE temporary factor sim withfactors for 1K assets  POPULATE temporary factor expo for 1K assets CALCULATE asset sims i.e. sum product of factor_sim and  factor_expofor 1K   assets (parallel execution)  TRANSPOSE asset sims in wideformat by converting market  returns into array format   for 1K assets SAVE asset sims to table (parallel execution)  CALCULATE CVAR inparallel for 1K assets  SAVE CVAR to asset measure table (parallelexecution)  CLEAR temporary tables  ADJUST no-of-target-assets withnumber of records processed  i.e. no-of-target-   assets =no-of-target-assets - 1000 CONTINUE LOOP

FIG. 40 shows an architecture for the MLPO. In FIG. 40, an entityrelationship diagram describing embodiments of a database with a set ofdatabase tables that may be utilized to facilitate operation of thedatabase calculation engine is illustrated.

FIG. 41 shows a screenshot illustrating user interface(s) of the MLPO.In FIG. 41, an exemplary user interface (e.g., for a mobile device, fora website) for constructing an optimized bond ladder portfolio isillustrated. Screen 4101 shows that a user may utilize a positions tab4105 to specify a universe of investment securities. The user mayutilize a set of strategy setting widgets 4110 to specify an investmentamount, a time horizon, a rung interval, a tax rate, a yieldmaximization method, and/or the like. The user may utilize a set ofsecurity selection widgets 4115 to specify a tax status, a set ofproducts (e.g., one or more of municipal, corporate, treasury, etc.), astate, a callable setting, a minimum credit rating, whether to includenon-rated bonds, a maximum security exposure, and/or the like. The usermay utilize a construct portfolio widget 4120 to initiate the creationof the optimized bond ladder portfolio.

FIG. 42 shows a screenshot illustrating user interface(s) of the MLPO.In FIG. 42, an exemplary user interface (e.g., for a mobile device, fora website) for constructing an optimized bond ladder portfolio isillustrated. Screen 4201 shows that the user may utilize a positions tab4205 to view proposed positions of the optimized bond ladder portfoliofor corporate product type. The user may utilize a set of proposedpositions widgets 4210 to view information regarding bond ladder rungsand/or regarding individual investment securities in each rung.

FIG. 43 shows a screenshot illustrating user interface(s) of the MLPO.In FIG. 43, an exemplary user interface (e.g., for a mobile device, fora website) for constructing an optimized bond ladder portfolio isillustrated. Screen 4301 shows that the user may utilize a positions tab4305 to view proposed positions of the optimized bond ladder portfoliofor municipal product type. The user may utilize a set of proposedpositions widgets 4310 to view information regarding bond ladder rungsand/or regarding individual investment securities in each rung.

FIG. 44 shows a screenshot illustrating user interface(s) of the MLPO.In FIG. 44, an exemplary user interface (e.g., for a mobile device, fora website) for constructing an optimized bond ladder portfolio isillustrated. Screen 4401 shows that the user may utilize a positions tab4405 to view proposed positions of the optimized bond ladder portfoliofor treasury product type. The user may utilize a set of proposedpositions widgets 4410 to view information regarding bond ladder rungsand/or regarding individual investment securities in each rung.

FIG. 45 shows a screenshot illustrating user interface(s) of the MLPO.In FIG. 45, an exemplary user interface (e.g., for a mobile device, fora website) for constructing an optimized bond ladder portfolio isillustrated. Screen 4501 shows that the user may utilize a portfolioanalysis tab 4505 to view portfolio characteristics of the optimizedbond ladder portfolio with no risk score adjustment. The user mayutilize a set of portfolio characteristics widgets 4510 to viewinformation regarding the various portfolio characteristics.

FIG. 46 shows a screenshot illustrating user interface(s) of the MLPO.In FIG. 46, an exemplary user interface (e.g., for a mobile device, fora website) for constructing an optimized bond ladder portfolio isillustrated. Screen 4601 shows that the user may utilize a portfolioanalysis tab 4605 to view portfolio characteristics of the optimizedbond ladder portfolio with risk score adjustment. The user may utilize aset of portfolio characteristics widgets 4610 to view informationregarding the various portfolio characteristics.

FIG. 47 shows a screenshot illustrating user interface(s) of the MLPO.In FIG. 47, an exemplary user interface (e.g., for a mobile device, fora website) for constructing an optimized bond ladder portfolio isillustrated. Screen 4701 shows that the user may view informationregarding market sensitivity of the optimized bond ladder portfolio. Theuser may utilize a set of market sensitivity widgets 4705 to viewinformation regarding market sensitivity of the optimized bond ladderportfolio for overall market scenarios, for specified predefinedscenarios, for specified business cycles, and/or the like over varioustime horizons.

Additional Alternative Embodiment Examples

The following alternative example embodiments provide a number ofvariations of some of the core principles already discussed for expandedcolor on the abilities of the MLPO.

FIG. 31 shows an architecture for the MLPO. In FIG. 31, an embodiment ofan AWS architecture that may be utilized to facilitate MLPO (alsoreferred to as ATIM in the figure) operation is illustrated.

FIG. 32 shows an architecture for the MLPO. In FIG. 32, an embodiment ofan AWS architecture that may be utilized to facilitate MLPO (alsoreferred to as ATIM in the figure) simulation calculation workflow isillustrated.

FIGS. 33A-B show an architecture for the MLPO. In FIGS. 33A-B, entityrelationship diagrams describing embodiments of a database with a set ofdatabase tables that may be utilized to facilitate MLPO operation areillustrated.

FIG. 48 shows an architecture for the MLPO. In FIG. 48, an embodiment ofa bond ladder construction process that may utilize asset return metricdata (e.g., CVaR in the asset measure table) provided by the databasecalculation engine is illustrated.

Enabling Unprecedented Market Stress Scenarios to be Generated Followingthe Observed Unprecedentedness Pattern from History

The unprecedentedness of a historical scenario is described as thenumber of Δ factors that take unprecedented values compared tohistorical scenarios prior to that date. The plot in FIG. 65 visualizesthe relationship between Δ VIX and historical unprecedentedness. In thisexample, a degree 2 polynomial is used to represent the relationshipbecause as Δ VIX becomes more extreme in both ends, greater number of Δfactors taking unprecedented values are expected to show up. The fitteddegree 2 polynomial curve is the historical unprecedentedness curve.

As shown in FIG. 65, a large VIX change comes with unseen changes inmarket risk factors.

The unprecedentedness of a transfer-layer VAE simulated scenario isdescribed to be the number of Δ factors that take unprecedented valuescompared to historical scenarios. The plot in FIG. 66 shows thatsimulation output from transfer-layer VAE fails to reflect the relationshown above, with almost all scenarios having 0 unprecedentedness. Thereason is that VAE restores the historical scenarios very well so it isnot surprising we are unable to see more extreme Δ factors values.

As shown in FIG. 66, a Deep Learning Model captures each factor'shistory closely but neglects other factors' related new extremes.

Following what has been done to calculate VAE unprecedentedness, we canapply it to panic simulated market scenarios. The goal is to make therelationship between Δ VIX and stress sim unprecedentedness to lookalike to the relationship in historical unprecedentedness section. Theapproach is to find the mean squared error between the unprecedentednesscurves. See FIGS. 68, 69, and 70.

For example, as shown in FIG. 67, by selecting historical scenarios witheither Δ VIX<−1000 or Δ VIX>3062 to compute mean and covariance and thenfit a multivariate normal distribution and sample the same number ofscenarios as in history, the relationship fitted from simulatedscenarios will be alike to the historical.

A component of the market scenario simulation is a deep learning model,variational autoencoder. To take advantage of the cloud compute power,in one implementation, a machine learning service, SageMaker, may beused in AWS. SageMaker is a fully managed service that provides anefficient way for developers and data scientists to collaborate togetherto build, train, tune, and deploy models in a machine learning pipeline.With SageMaker, the model training and tuning process can beconveniently run in a parallel and distributed way on multiple instancesand multiple GPUs. In addition, the one-click deployment feature ofSageMaker significantly reduces the effort to deploy a machine learningmodel. For example, with the parallel computing architecture usingSageMaker, the training time of multiple models may be reduced to 2minutes in total, while training multiple models sequentially withsingle instance and single CPU takes 45 minutes, as shown in FIG. 72.

Simulating Mutual Fund and ETF Asset Returns

The Mutual Fund and ETF returns simulation model employs a set ofmachine learning techniques to estimate 3-month, 6-month and 1-yearreturns under simulated market scenarios while allowing for domainexperts to incorporate their subjective views. FIG. 49 illustrates theoverall model architecture. In one implementation, parallel computingmay be used to implement training and deployment of a unique model foreach mutual fund or ETF. As FIG. 50 demonstrates, the process of loadingdata from database tables, performing feature engineering, trainingmodel and writing results to database may be distributed to multipleprocessors and conducted simultaneously. FIG. 51 summarizes the databasetables containing model input and output. For each fund or ETF, thereturns during specified investment horizons are aggregatedgeometrically from daily returns. Domain experts have the option ofspecifying a pool of potential market factors to be considered by thefeature selection procedure for a particular fund or ETF. If no factorsare specified by experts, available market factors will be considered.To select the set of market factors that contribute the most to overallmodel performance and mitigate the problem of multicollinearity, aproprietary feature selection procedure is designed to utilize XGBoostto rank the feature importance levels of available market factors, andfeed the factors with positive importance scores to a customized forwardselection process, which selects a set of factors that maximizes themodel's adjusted R-squared as well as restrains model coefficients fromchanging signs (see FIG. 52). Subsequently, a Ridge Regression model istrained to learn the relationship between a fund's or ETF's historicalreturns and those of the selected set of market factors using 75% ofhistorical data points, is validated using the remaining 25% ofhistorical data points based on a number of metrics, includingout-of-sample adjusted R-squared, effect size of residual distribution,residual correlation, etc., and is utilized to estimates its returnsunder stimulated market environments. FIG. 53 illustrates the marketrisk factor exposures based on the regression models as presented in theUI. To account for a fund or ETF's active risk not captured by commonmarket factors, regression residuals from the model validation stage arerandomly sampled and added to the simulated fund or ETF returns. Lastly,the estimated returns may be calibrated to reflect capital marketassumptions provided by economists. FIGS. 54 and 55 present thedistributions of simulated returns under user-defined market scenariosand different business cycles, respectively.

Simulating Equity Asset Returns

Individual Equity returns for different time horizons are aggregatedgeometrically with daily return, which is adjusted for corporate actionssuch as stock split and dividend. Daily return may be used instead ofprice because price can have huge jump caused by corporate actions.Feature selection may be utilized before model training. It uses anXGBoost model to select a subset of features that contribute to positivegain in feature importance ranking and then feeds these selectedfeatures to a forward selection process, which further extracts featuresthat improve adjusted R square (see FIG. 56). Both Ridge regression(e.g., used in forward selection with adjusted R square) and XGBoostregression at the last step deal with multi-collinearity problem. Basedon the CAPM model, an asset's risk has 2 components: one is market riskdriven, one is idiosyncratic risk driven. Building the 2 partsseparately allows models to better capture the behavior of differentrisk components. Intuition for conditional beta modeling is that basedon historical observation, equities' correlation to market index canvary under different market scenarios, and correlation from differentequities can also vary. Conditional beta model captures individualequity's sensitivity to market index across the simulated marketscenarios and formulates the market risk driven part. Intuition foridiosyncratic risk modeling is that based on historical observation,beta risk from broad market index partially explains an equity's totalreturn, and the other key part is company specific risk, which in thiscase is revealed from company financials data and default probability.Combining conditional beta model and idiosyncratic risk model, a morecomprehensive total risk simulation is generated matching the CAPM'sexplanation. During training phase, realized beta is calculated usinglinear regression of individual equity's return series against marketindex's return series for a selected time horizon. Modeling for 3 M, 6M, and 12 M are separated since market scenario simulation andfinancials factors capture their own dependencies under different timehorizons. To account for residual analysis, a few validations weredone. 1. Effective size (Cohen's D measure) was close to zero. 2.Residual correlation to target variable was close to zero. 3. Residualwas unbiased. Residuals are stored during training phase, randomlysampled during scoring phase, and added to simulated conditional beta tobetter capture market driven risk. Conditional beta modeling uses broadcommon market risk factors as features, including macro factors, equityindices, and smart beta factors. To simulate individual equity'sconditional beta against market index, simulated market scenarios areused. Conditional beta modeling may be implemented with parallelcomputing on EMR notebook, which uses AWS cloud environment and utilizesclusters to do the training Generated models for each individual equitymay be directly written into a Postgres database in binary formatthrough a driver (see FIG. 62). Company specific returns are modeledwith feature importance weighted historical sampling. During modeltraining phase, feature importance is stored. During scoring phase, if asimulated market scenario can be mapped to individual equity's existinghistorical scenario, then the excess return over market index for thisspecific historical scenario is used. Otherwise, a Euclidian distance iscalculated weighted by feature importance from selected risk features,and excess return over market index for the closest historical scenariois used. Total return is calculated combining beta return andidiosyncratic return. Simulated returns for each equity are stored in anarray format in Postgres table.

EMR Notebook is used in simulating asset returns concurrently on CloudTechnology platform for mutual funds, ETFs, equities and fixed incomeinstruments. In Financial Services Industry, as data sets grow rapidlyand complexly, the data transformation, data storage, and the users'real-time operations end up with a huge burden. Big data frameworks maybe employed to support the data process and storage, and they allow thedata to be generated and stored in a parallel and distributed way. Sparkand Hadoop are examples of compute engines for big data that may beutilized. The principle of the compute engine in Spark is to analyzecomputation tasks and optimize the workflow of the data processingbefore actually executing the code. Spark may utilize Directed AcyclicGraph (DAG) optimizations and in memory processing.

Spark has been integrated into many cloud services, such as Elastic MapReduce (EMR) provided by Amazon Web Service (AWS). In oneimplementation, EMR may be utilized to make full usage of compute poweroffered by the cloud provider and save compute costs, since the EMRruntime for Spark can be over 3 times faster than standard Spark. Usingcloud provided service may help to improve the performance of workloadswithout making extra changes to the applications.

In one implementation, in order to improve the development efficiency,EMR Notebooks may be used along with EMR clusters to submit Spark jobsfor parallel computing. EMR Notebook is a managed notebook environmentwhich is based on the open-source Jupyter notebook. It supportssubmitting Spark code to EMR clusters through Apache Livy.

In one implementation, the Optimizer is developed based on parallelcomputation capability and advanced numerical optimizationmethodologies, such as Tail Risk Optimizer and Mean-Variance Optimizer,in order to provide optimal portfolio within 3 M, 6 M and 1 Y horizonand user specified conditions. It evaluates the portfolio expectedreturn, portfolio volatility and portfolio drawdown, equipped withflexible scenarios choices and business Cycle overview.

For Tail Risk Optimizer, mixed integer programming, binary integerprogramming and linear programming with rounding techniques areavailable. CVaR-Mean frontier can be shaped with the optimizer parallelcomputation ability and then illustrate the relationship between CVaRand expected return. Different CVaR-Mean frontier can be visualizedaccording to diversification preferences (see FIG. 71) and marketscenarios. The mixed integer programming can offer more accurate resultsaccording to asset price and asset tradable amount while the linearprogramming with rounding techniques guarantees faster performance onlarge scale computation (See FIG. 72).

For the Mean-Variance Optimizer, the portfolio risk is measured bycovariance matrix that can be estimated through two different methods inthe tool. “Shifted Diagonal” method adjusts original sample covariancematrix diagonal to decrease asset correlation influence in optimization,and “Ledoit-Wolf” method gives a robust estimation by minimizing thequadratic loss function.

In one implementation, the optimizer attempts to maximize the portfolioreturn with a risk penalty whose value is decided by risk toleranceparameter. The 0 risk tolerance will lead the optimizer to minimize therisk at all costs and the infinity risk tolerance will maximize thereturn at all costs. In the tool, the risk tolerance has been mappedfrom 0 to 10 to be user friendly.

Similarly, the efficient frontier of Mean Variance Optimizer can bepresented according to investors' preferences as well as various marketscenarios. Optimal portfolio weights may be generated varying riskaversion in the convex optimization with user specified weightsconstrains and market scenario. This set of optimal solutions theoptimizer generated would form a frontier line and the optimal solutionof current risk tolerance level would be a big red dot on the previousfrontier and should move along on the efficient frontier when risktolerance parameter changes (see FIG. 73). Thus, the change of risktolerance level may not change the efficient frontier shape, but thechanges of diversification and market scenarios may lead to a reshapedefficient frontier (see FIG. 74 and FIG. 75).

Multi-Risk Factor Risk Engine and Portfolio Aggregation Using Oracle RDSon Cloud

Using Oracle RDS on Cloud, a SQL-based solution effectively utilizesdifferent parallel execution techniques for calculating simulation data.Conditional risk simulation can now be calculated for over a millionassets using a faster, simple, cost effective and scalable solutionusing Oracle RDS on Cloud in substantially less amount of time.Computations happens on the database server, eliminating having totransfer a huge set of data to external systems for processing andtherefore maximizes processing of data using cloud computing.

The first step of the process is to calculate Factor Exposures foravailable assets as shown in FIG. 76. Based on available reference dataand analytics, the spread ratio is calculated for the available assetsin parallel. The second step is to calculate simulated returns for theavailable assets as shows in FIG. 77. The process of generatingsimulated asset returns may involve, getting unique list of assets forwhich exposure data is available and loading the factor exposures forassets with exposure to the factors and loading factor simulations forthose factors (see FIG. 78). The process then splits the workload intosmaller chunks with each chunk processing a subset of the assets. Thesimulated returns for the assets are then calculated, adjusted usingavailable call and put schedule, and written to the database usingseveral parallel computing techniques as listed below (see FIG. 79).

Convexity Adjustment—To integrate the impact of convexity in assetsimulation, it may be included as an additional term in the dot productfollowing these steps. The convexity metric (option adjusted convexity)is obtained from Sentinel's security_master table.

Step 1: Insert convexity as two new “factors” (id 80 for non-muniinstruments, 81 for muni instruments) in the factor_expo table (see FIG.80).Step 2: For each simulation id and each market scenario (market id),insert the square of the change in yield as two new “factors” (id 80 forTreasury curves, 81 for muni curves) in the factor_sim table. In oneimplementation, the average return of different key rates may be used asthe proxy for the change in yield (see FIG. 81).

-   -   Treasury Curves 3 M, 6 M, 1 Y, 2 Y, 3 Y, 5 Y, 7 Y, 10 Y, 20 Y,        30 Y    -   Muni Curves 2 Y, 5 Y, 10 Y, 20 Y

Optionality Adjustment—If an instrument has an embedded call (or put)option redeemable within the investment horizon, the return fromexercising the call (or put) option may be set as the upper (or lower)bound of the simulated asset return. The call (or put) option schedules,including redemption dates and prices, are obtained from Sentinel'scall_schedule (or put_schedule) tables (see FIG. 82).

In one implementation, several data reduction, scaling and parallelcomputing techniques may be utilized. For example, innovative ways touse global temporary tables and sessions, data reduction techniques todrastically limit amount of data utilized for processing thus loweringprocessing time, and several other data parallelization techniques forgenerating simulation data may be utilized.

1. Use of Multiple Batches to achieve higher degree of parallelism (DOP)2. Use of Global Temporary Tables (GTT) to be able to run batch inmultiple sessions and reduce temporary storage requirements3. Use of Data Reduction techniques to reduce full table scans for joinsbetween Factor Exposure and Factor Simulation table4. Use of Parallel Query to parallelize generation of Asset Simulationand Contribution to Value at Risk data5. Use of Parallel DML to parallelize inserting data related to AssetSimulation and Contribution to Value at Risk6. Use of DDL for faster execution of delete statements to speed upcleanup of global temporary tables (see FIG. 79)

Tail-Risk Adjusted Bond Ladder Construction

Tail-risk adjusted bond ladder construction is the capability toconstruct a bond ladder incorporating real-time market offerings,user-defined search criteria, and pre-trade scenario risk analysis (seeFIG. 93). In some implementations, the tail-risk adjusted bond ladderconstruction process is a rule based approach that avoids the use of asolver, which allows a large number of bond market offerings to beevaluated in real-time, guarantees portfolio construction solutionsbased on market offerings, and provides consistent and scalablecalculation performance. The bond-ladder construction logic (see FIG.88) uses the real-time bond offering from electronic bond tradingvenues. Real-time data fusion technologies provide the list of bonds andprices from multiple sources of liquidity. The logic also ensures themarket values across the rungs of the bond ladder are approximatelyequal (see FIG. 94). The proposed bond ladder is built withapproximately equal market values across the different rungs of the bondladder (see FIG. 95). Market value is calculated using allocated paramount and prices from real-time bond offerings.

In one implementation, the bond ladder construction may use two separatemodes—Yield Maximization and Risk Score Adjusted to construct the ladder(see FIG. 93). Under Yield Maximization mode (see FIG. 96), theofferings are first organized into classifications according to producttype, credit rating, and final maturity. The classifications can then befurther screened by user-defined search criteria resulting with the(e.g., one hundred) highest yielding securities presented per rung asladder portfolio options. Ladder options may be allocated within theportfolio up to a user-defined diversification constraint (“MaximumSecurity Exposure”). By doing this, the user can specify that the marketvalue of any individual position should not exceed a percentagethreshold of the total market value of the portfolio. Under Risk ScoreAdjusted mode (see FIG. 97), the offerings are first organized intoclassifications according to product type, credit rating, and finalmaturity. The classifications can then be further screened byuser-defined search criteria. The resulting set of securities are thenrun through the model which takes the offering yield to worst andperforms a calculation on each to arrive at a down-side risk score.Down-side risk is quantified using a statistical measure calculated as azscore, sourced from either the security's default probability or its 5%worst mark-to-market estimated total returns, also known as the 5%conditional value-at-risk (CVaR).

For bonds which are covered by Kamakura Corporation's default riskmodel, default probabilities may be used as the down-side risk score.Default probabilities are published daily by Kamakura for public,private and sovereign issuers across multiple time horizons. Defaultprobabilities may be updated for these issuers using the followingtenors: 1 Month, 3 Months, 6 Months, 1 Yr, 2 Yr, 4 Yr, 5 Yr, 7 Yr, 10Yr. These time horizons are matched with the time to maturities of thebonds in the bond offerings. For bonds not covered by Kamakura's defaultrisk model, down-side risk may be quantified as CVaR calculated based ona proprietary risk model. A normalized risk score is calculated foravailable bond offerings for each rung. The bonds' yield to worst may beadjusted by the risk score. Bond offerings with lower down-side riskrank higher; bond offerings with higher risk rank lower.

Steps for Tail-Risk Adjusted Bond Ladder Construction

1. Get Available Bonds from Offers API based on inputs provided in theStrategy Settings and Security Selected screen of Bond Beacon (see FIG.89)2. Check if Risk Score Adjustment option is selected as the YieldMaximization Method. If Yes, continue with Step #3 below otherwise,continue to Step #5.3. Calculate and store MEAN and STDDEV based on data available forConditional Value at Risk (CVAR) and Default Probability. These valueswill be used later to calculate z-score and adjustment to yield.4. Check each security available for allocation and adjust their yield

-   -   a. If the security has default probability, calculate z-score        using the following formula

z-score=(DEFAULTinstrument−DEFAULTmean)/DEFAULTstddev

Adjusted Yield=yield*(1−z-score/10)

-   -   b. If no default probability data is available for the security,        calculate z-score based on the following formula

z-score=(CVARinstrument−CVARmean)/CVARstddev

Adjusted Yield=yield*(1+z-score/10)

5. Run the bond allocation logic based on Adjusted Yield. If No RiskScore Adjustment option is selected, Adjusted Yield equals to the Yieldof the security (see FIG. 90 for output generated from the bond ladderconstruction logic).

-   -   a. Sort available bonds based on Adjusted Yield, Rating and        Available Quantity to Trade    -   b. Calculate Quantity to Allocated in PAR for security based on        Minimum Denomination, Minimum Increment and Diversification        Limit (in MV)    -   c. Check for Minimum Balance Remaining based on Calculated        Quantity to Allocate. If Minimum Balance Remaining Condition is        not satisfied, skip the bond and continue.    -   d. Check if the rung has enough cash for allocation based on        allocated MV for security.        -   i. If rung has enough cash, allocate and adjust rung MV        -   ii. If run does not have enough cash, repeat step 5.a using            available rung's cash as the limit Continue with steps 5.a,            5.b and 5.c.            6. Check if Residual Cash is remaining after Bond Allocation    -   a. Find Rung with highest yield.        -   i. Using bonds currently allocated within a rung, find the            yield based on weighted average calculations.        -   ii. Find the rung with the highest average yield.    -   b. For all bonds currently available in the rung, run the bond        allocation logic as listed in Step #5

Scenario-Based Risk Reporting for Multiple User-Specified Scenarios

Scenario-based Risk Reporting may be implemented as part of anapplication programming interface (API) which uses parallel processingfor calculating risk-based analytics for user specified scenarios.

The first step of the process is to load simulated returns for availablesecurities in parallel (see FIG. 83). If simulated returns are notavailable for the specified securities (see FIG. 91), a real-time assetsimulation process is executed. This real-time process generates thesimulated returns for the securities in real-time by applying datareduction methods for loading factor exposures and simulated factorreturns from the database (see FIG. 87) for the factors the securitieshas exposures to. The data reduction method reduces the data loaded forcalculating the simulated returns by reducing the data to the factorsthe securities have exposures to. This eliminates redundant data beingloaded and supports the factor executing of dot product calculationsutilized for generating the simulated returns (see FIG. 86).

The second step is to filter out markets based on the input scenarios(occurrence of a situation or changes to key factor such as, change ininterest rates) or business cycles (a business cycle is the natural riseand fall of economic growth that occurs over time) specified by theuser. For example, if user has created a scenario with a criteria inwhich the U.S. 2 Year Treasury Rate is between 0.3 and 1.8%, the processcreates a map of markets for which the simulated returns for securitiesfalls within this range. The process is executed in parallel foravailable user-defined scenarios and specified securities. If aparticular user-defined scenario has multiple such criteria, additionalfilter logic is applied on top of previously filtered markets. Once thetarget list of markets is available for each user-defined scenario, theprocess filters the simulated returns for securities and reduces thedata to the targeted markets available.

The final step is to calculate the weighted average simulated returnsfor the filtered markets based on the weight specified as part of theinput for each security. The process then calculates risk-levelanalytics such as, CVAR based on filtered simulated returns. The resultsare then presented to the user (see FIG. 92). FIG. 98 shows the MarketSensitivity Chart that shows how a particular portfolio performs underdifferent user-defined scenarios and business cycles.

Additional embodiments may include:

Generate Simulated Market Scenarios Using a Set of Deep Learning NeuralNetworks and Multivariate Mixture with Cloud Computing

1. A machine learning portfolio generating apparatus, comprising:

-   a memory;-   a component collection in the memory;-   a processor disposed in communication with the memory and configured    to issue a plurality of processor-executable instructions from the    component collection, the processor-executable instructions    structured as:-   generate, via at least one processor, a set of simulated market    scenarios using a variational autoencoder with cloud computing    technology, the variational autoencoder structured as:    -   use neural networks as encoder to generate a set of latent        variables, simulate latent variables with neural networks as        decoder such that the decoded simulated market scenarios follow        dynamic dependencies and volatilities of historical market risk        factors;    -   use a transfer layer between the encoder and the decoder to        allow latent space variables to take on any distributions and        any dependency joint distribution structures;    -   in which the number of latent space variables, the number of        neurons in the encoder and the decoder and the number of layers        of the encoder and the decoder are tuned to ensure an overall        goodness of fit between the set of simulated market scenarios        and a set of historical market scenarios.        2. The apparatus of embodiment 1, further, comprising:-   the instructions from cloud computing technologies to determine the    set of historical market scenarios are structured to comprise    instructions to:    -   determine, via at least one processor, a historical data set, a        rolling window period length, and a set of market factors;    -   determine, via at least one processor, a set of rolling window        periods using the historical data set and the rolling window        period length; and    -   calculate, via at least one processor, for each market factor        from the set of market factors, for each rolling window period        from the set of rolling window periods, a change to the        respective market factor during the respective rolling window        period,        -   each historical market scenario from the set of historical            market scenarios structured to comprise calculated changes            to the set of market factors during a rolling window period.            3. The apparatus of embodiment 2, further, comprising:-   the instructions with cloud computing technologies to calculate a    change to a market factor during a rolling window period are    structured to comprise instructions to:    -   determine, via at least one processor, the delta between values        of the market factor at a beginning time point and an ending        time point of the rolling window period.        4. The apparatus of embodiment 3, further, comprising:-   the processor-executable instructions on cloud computing clusters    structured as:    -   determine, via at least one processor, that historical data for        the market factor during the rolling window period is        unavailable for a time point; and    -   impute, via at least one processor, the unavailable historical        data for the time point using a machine learning method, the        imputed delta of historical market factors structured to        minimize the Mean Absolute Difference between correlation        matrices of original and imputed data, in which the mean        z-scores of market factor deltas with imputation are minimized        compared to the mean z-scores of the original market factor        deltas without imputation, and in which the ratios of the        standard deviation of each factor with and without imputation        approach 1.        5. The apparatus of embodiment 1, further, comprising:-   he processor-executable instructions on cloud computing clusters    structured as:    -   utilize a deep learning neural network for a time period bucket,        the trained deep learning neural network is trained to generate        a set of Gaussian mixture latent variables.        6. The apparatus of embodiment 5, further, comprising:-   the processor-executable instructions on cloud computing clusters    structured to generate simulated market scenarios for the time    period bucket, using the trained deep learning neural network    associated with the time period bucket.    7. The apparatus of embodiment 6, further, comprising:-   the instructions to generate simulated market scenarios for the time    period bucket are structured to comprise instructions to:    -   generate, via at least one processor, a set of random values for        the set of Gaussian mixture latent variables; and    -   generate a simulated market scenario, from the simulated market        scenarios for the time period bucket, from the generated set of        random values using a neural network decoder of the trained deep        learning neural network associated with the time period bucket.        8. The apparatus of embodiment 1, further, comprising:-   the processor-executable instructions structured as:    -   filter, via at least one processor, the set of simulated market        scenarios associated with a time period length based on        specified ranges of allowable values for specified customized        market factors.        9. The apparatus of embodiment 1, further, comprising:-   the processor-executable instructions structured as:    -   filter, via at least one processor, the set of simulated market        scenarios associated with a time period length based on        specified business cycle settings.        10. The apparatus of embodiment 1, further, comprising:-   the instructions to train a machine learning process to generate    unprecedented stress market scenarios structured as:    -   quantify unprecedentedness as a fitted polynomial degree 2        curve, via at least one processor on cloud computing        infrastructure, which captures the relationship between        movements in VIX and the number of risk factors that experienced        unprecedented magnitude of changes; and    -   train, via at least one processor on cloud computing platform,        the conditional dependency structure of large movements in VIX,        -   in which the VIX up and VIX down levels are solved by the            objective function of minimizing the mean squared error            between a simulated polynomial degree 2 curve and a            historical polynomial degree 2 curve,        -   in which the fitted polynomial degree 2 curve is fitted from            simulated market scenarios generated using at least one of:            a variational autoencoder deep learning model, a gaussian            copula conditional on large VIX movements.            11. The apparatus of embodiment 1, further, comprising:-   the processor-executable instructions structured as:    -   apply cloud service, Amazon Web Services (AWS) SageMaker, to        train, tune, and deploy deep learning models in a parallel and        distributed way on multiple instances and multiple GPUs.        12. The apparatus of embodiment 1, further, comprising:-   the processor-executable instructions structured as:    -   use a machine learning service, SageMaker, in AWS to manage        machine learning pipeline.        13. The apparatus of embodiment 1, further, comprising:-   the processor-executable instructions structured as:    -   utilize SageMaker to support collaboration between developers        and data scientists.        14. The apparatus of embodiment 1, further, comprising:-   the processor-executable instructions of using SageMaker for    parallel market scenario simulation structured as:    -   create a SageMaker notebook instance with specific lifecycle        configuration, permissions and encryption, and network settings;    -   upload input data to S3 by providing a S3 path;    -   configure a training job as an estimator by providing arguments        including at least one of: training script entry point,        SageMaker execution role, number and type of training instance,        security key, and a set of hyperparameters;    -   trigger the training job by launching a docker container on EC2        instances with prebuilt SageMaker docker images and downloading        the input data from the specified S3 path to start the training        process;    -   repeat the training job on market scenarios with different delta        length to configure multiple training jobs such that they can be        triggered together and trained on multiple instances in a        parallel way;    -   deploy models as multiple SageMaker endpoints by specifying        instance type and number of instances used to host the        endpoints; and simulate market scenarios with different delta        length using the SageMaker endpoints.

Simulating Mutual Fund and ETF Returns with Machine Learning and CloudComputing Techniques

1. A machine learning mutual fund and ETF returns simulating apparatus,comprising:

-   a memory;-   a component collection in the memory;-   a processor disposed in communication with the memory and configured    to issue a plurality of processor-executable instructions from the    component collection, the processor-executable instructions    structured as:    -   obtain, via at least one processor, mutual funds' or ETFs'        historical daily returns data sets, a set of rolling window        period lengths, and data sets for a set of market factors'        historical returns during the specified set of rolling window        periods;    -   compute, via at least one processor, for each mutual fund or        ETF, returns during each rolling window period from the set of        rolling window periods, by aggregating the historical returns;    -   learn, via at least one processor, for each mutual fund or ETF,        for each rolling window period from the set of rolling window        periods, the respective mutual fund's or ETF's relationships        with a set of most relevant market factors from their historical        returns;    -   simulate, via at least one processor, for each mutual fund or        ETF, for each rolling window period from the set of rolling        window periods, the respective mutual fund's or ETF's returns        under simulated market scenarios;    -   visualize real-time, via at least one processor, for each mutual        fund, ETF, or portfolio of mutual funds and ETFs, for each        rolling window period from the set of rolling window periods,        the respective mutual fund's, ETF's, or portfolio's simulated        returns distributions under user-specified market scenarios or        business cycles; and    -   illustrate, via at least one processor, for each mutual fund or        ETF, for each rolling window period from the set of rolling        window periods, the respective mutual fund's or ETF's exposure        to each market factor.        2. The apparatus of embodiment 1, further, comprising:-   the processor-executable instructions structured as:    -   construct, via at least one processor, from a set of market        factor pairs, a set of spread factors, by computing the        difference in returns between each pair of market factors under        simulated market scenarios, the set of spread factors comprising        orthogonal features that mitigate multicollinearity;    -   update, via at least one processor, the set of market factors to        include the set of spread factors; and    -   select, via at least one processor, for each mutual fund or ETF,        the set of most relevant market factors to utilize during        simulation model training.        3. The apparatus of embodiment 2, further, comprising:-   the processor-executable instructions structured as:    -   obtain, via at least one processor, from database tables, for        each mutual fund or ETF, domain experts' input that specifies a        set of utilization market factors to be considered for        utilization in the return-simulating model, based on the fund or        ETF's asset category;    -   evaluate, via at least one processor, for each mutual fund or        ETF, for each market factor in the set of utilization market        factors, the importance level of the market factor's impact on        the mutual fund's or ETF's returns, using XGBoost's feature        importance measurement; and    -   select, via at least one processor, for each mutual fund or ETF,        from the domain-expert-specified or entire set of market        factors, the top contributing market factors to be later        utilized in the return-simulation model, using a customized        forward selection algorithm that maximizes regression models'        adjusted R² and restrains model coefficients from flipping        signs, the top contributing market factors selected to alleviate        multicollinearity.        4. The apparatus of embodiment 3, further, comprising:-   the processor-executable instructions structured as:    -   train, via at least one processor, for each mutual fund or ETF,        for each rolling window period from the set of rolling window        periods, using the selected set of market factors, a ridge        regression model which regularizes regression coefficients and        mitigates multicollinearity;    -   evaluate, via at least one processor, for each mutual fund or        ETF, for each rolling window period from the set of rolling        window periods, model performance by measuring adjusted R² and        conducting residual distribution analysis; and    -   store, via at least one processor, for each mutual fund or ETF,        for each rolling window period from the set of rolling window        periods, a binary format of the trained ridge regression model        and model performance evaluation metrics in one or more database        tables.        5. The apparatus of embodiment 4, further, comprising:-   the processor-executable instructions structured as:    -   simulate, via at least one processor, for each mutual fund or        ETF, for each rolling window period from the set of rolling        window periods, the returns under the simulated market        scenarios, using the trained ridge regression model;    -   adjust, via at least one processor, for each mutual fund or ETF,        for each rolling window period from the set of rolling window        periods, the respective mutual fund's or ETF's        market-factor-based simulated returns for idiosyncratic risk, by        adding sampled regression residuals; and    -   calibrate, via at least one processor, for each mutual fund or        ETF, for each rolling window period from the set of rolling        window periods, the respective mutual fund's or ETF's returns to        forward-looking capital market assumptions.        6. The apparatus of embodiment 5, further, comprising:-   the processor-executable instructions structured as:    -   calculate, via at least one processor, for each mutual fund or        ETF, for each rolling window period from the set of rolling        window periods, the correlation between the sampled regression        residuals and a target variable;    -   evaluate, via at least one processor, for each mutual fund or        ETF, for each rolling window period from the set of rolling        window periods, a distribution of the sampled regression        residuals by conducting the Mann-Whitney U Test;    -   assess, via at least one processor, for each mutual fund or ETF,        for each rolling window period from the set of rolling window        periods, the distance of the residual mean from 0 by calculating        Cohen's d.        7. The apparatus of embodiment 1, further, comprising:-   the processor-executable instructions structured as:    -   utilize big data framework, Spark, with Elastic Map Reduce (EMR)        and EMR Notebook, to support processing and storage in a        parallel and distributed way.        8. The apparatus of embodiment 7, further, comprising:-   the processor-executable instructions structured as:    -   utilize Spark to analyze computation tasks and optimize        processing workflow prior to code execution.        9. The apparatus of embodiment 8, further, comprising:-   the processor-executable instructions structured as:    -   use EMR Notebooks along with EMR clusters to submit Spark jobs        for parallel computing.        10. The apparatus of embodiment 9, further, comprising:-   the processor-executable instructions structured as:    -   execute EMR using a cloud computing infrastructure.        11. The apparatus of embodiment 10, further, comprising:    -   EMR Notebook is structured to provide at least one of the        following features: support for multiple programming languages,        test and debug code interactively, monitor Spark activity from        within a notebook, visualize large datasets and resume at broken        steps, and detach and attach a notebook to different EMR        clusters.        12. The apparatus of embodiment 7, further, comprising:-   the processor-executable instructions structured as:    -   create an EMR cluster with a predefined bootstrap script        including the dependencies utilized by a service;    -   execute the predefined bootstrap script on each worker node in a        cluster script to have dependent libraries installed;    -   create an EMR Notebook with a pre-defined service Identity and        Access Management (IAM) role and connect the EMR Notebook to the        EMR cluster;    -   load input data into the EMR cluster and store among core nodes        in a distributed way once the EMR cluster is in ready status;    -   group assets by the asset id and apply Spark mapper and reducer        functions on each asset to conduct a series of transformations        and reductions; and    -   save a trained model in binary format or predicted scores by the        trained model into Postgres database after the series of        transformations and reductions are conducted.        13. The apparatus of embodiment 1, further, comprising:-   the processor-executable instructions structured as:    -   provision an event-driven, self-service, and extensible big data        and machine learning self-service computation engine using a        collection of components implemented in a Workflow Declaration        Language (WDL).        14. The apparatus of embodiment 1, further, comprising:-   the processor-executable instructions structured as:    -   declaratively define a desired state of big data and machine        learning pipelines;    -   programmatically transform the desired state into a workflow;    -   generate workflow code associated with the workflow for resource        provision, job submission, job scheduling, job monitoring and        job dependency orchestration; and    -   inject the workflow code into a container for scheduling and        execution.        15. The apparatus of embodiment 1, further, comprising:-   the processor-executable instructions structured as:    -   utilize a plurality of platform-executable jobs derived from big        data and machine learning artifacts, structured to execute with        desired or elastic capacity on a variety of platforms and        services including at least one of: multi-node clusters, virtual        servers, containers and lambda functions.        16. The apparatus of embodiment 1, further, comprising:-   the processor-executable instructions structured as:    -   utilize an event-driven architecture with loosely coupled event        producers and consumers, integrated to:        -   fulfill the prescription of resource allocation;        -   generate workflow code to facilitate self-service;        -   provision vertical and horizontal scalability; and        -   support fault-tolerance.            17. The apparatus of embodiment 1, further, comprising:-   the processor-executable instructions structured as:    -   utilize parallel on parallel hierarchy and flexible calculation        dependencies, structured to facilitate multiple jobs to be        concurrently distributed to multiple nodes with tasks in each        job executed in parallel.        18. The apparatus of embodiment 1, further, comprising:-   heterogenous platforms consists of EMR, EC2, ECS and Lambda    functions;-   a set of supported languages: Scala, Java and Python.    19. The apparatus of embodiment 1, further, comprising:-   generic roles and responsibilities defined as interfaces for    functional implementation;-   open source technologies adopted to ensure cloud provider    agnosticism.    20. The apparatus of embodiment 1, further, comprising:-   the processor-executable instructions structured as:    -   utilize network-optimized, memory-optimized or compute-optimized        cloud instances.        21. The apparatus of embodiment 1, further, comprising:-   an optimization with cost leveraging:    -   inexpensive and commodity-grade virtual servers;    -   price-discount with Spot Instances or Reserved Instances.        22. The apparatus of embodiment 1, further, comprising:-   the processor-executable instructions structured as:    -   utilize a unified, distributed, parallel, generic computation        engine supporting big data batch and streaming processing for        financial data extraction, transformation, and load (ETL) and        simulation.

Simulating Equity Returns Under Different Market Scenarios Using a Setof Machine Learning and Cloud Computing Techniques

1. A machine learning equity returns simulating apparatus, comprising:

-   a memory;-   a component collection in the memory;-   a processor disposed in communication with the memory and configured    to issue a plurality of processor-executable instructions from the    component collection, the processor-executable instructions    structured as:    -   obtain, via at least one processor, equity's historical daily        returns data sets, a set of rolling window period lengths, and        data sets for the set of market factors' historical returns        during the specified rolling window periods;    -   compute, via at least one processor, for each equity, the        returns during each rolling window period from the set of        rolling window periods, by aggregating the historical daily        returns;    -   construct, via at least one processor, from a set of market        factor pairs, a set of spread factors, by computing the        difference in returns between each pair of market factors under        simulated market scenarios, in order to create orthogonal        features to mitigate the problem of multicollinearity;    -   update, via at least one processor, the set of market factors to        include the set of spread factors;    -   evaluate, via at least one processor, for each equity, for each        market factor in the updated set of market factors, the        importance level of the market factor's impact on the equity,        using XGBoost's feature importance measurement;    -   allow, via at least one processor, for each equity, from the        updated set of market factors, domain experts to specify market        factors to be later considered for utilization in the        return-simulating model, based on its asset category (e.g.,        fixed income, US equity, international equity, etc.);    -   select, via at least one processor, for each equity, from the        entire or domain-expert-specified set of market factors, the top        contributing market factors to be later utilized in the        return-simulating model, using a customized forward selection        algorithm that maximizes regression models adjusted R², in order        to enhance model performance and alleviate the issue of        multicollinearity;    -   learn, via at least one processor, for each equity, for each        rolling window period from the set of rolling window periods,        its relationships with the set of selected market factors from        their historical returns using ridge regression which        regularizes regression coefficients and mitigates the problem of        multicollinearity;    -   simulate, via at least one processor, for each equity, for each        rolling window period from the set of rolling window periods,        its returns under simulated market scenarios using XGBoost        regression with the set of selected market factors and company        specific financial factors;    -   calibrate, via at least one processor, for each equity, for each        rolling window period from the set of rolling window periods,        the returns to forward-looking capital market assumptions;    -   visualize real-time, via at least one processor, for each        equity, or portfolio of equities, for each rolling window period        from the set of rolling window periods, its simulated returns        distributions under user-specified market scenarios (e.g.,        business cycle assumption, rising VIX scenario, etc.); and    -   illustrate, via at least one processor, for each equity, for        each rolling window period from the set of rolling window        periods, its exposure to selected market factor based on their        historical returns.        2. A machine learning equity returns model feature engineering        apparatus, comprising:-   a memory;-   a component collection in the memory;-   a processor disposed in communication with the memory and configured    to issue a plurality of processor-executable instructions from the    component collection, the processor-executable instructions    structured as:    -   obtain, via at least one processor, equity's historical        conditional betas data sets, a set of rolling window period        lengths, data sets for the set of market factors' historical        returns during the specified rolling window periods, and data        sets for the set of company specific financials factors'        historical values during the specified rolling window periods;    -   compute, via at least one processor, for each equity, during        each rolling window period from the set of rolling window        periods, the set of features contributing to a positive gain in        feature importance ranking, by running nonparametric Gradient        Boosting tree regression model; and    -   further compute, via at least one processor, for each equity,        during each rolling window period from the set of rolling window        periods, the smaller set of features contributing to a positive        gain in adjusted R square, by running parametric regression        model, in order to enhance model performance and alleviate the        issue of multicollinearity.        3. A residual validation workflow apparatus, comprising:-   a memory;-   a component collection in the memory;-   a processor disposed in communication with the memory and configured    to issue a plurality of processor-executable instructions from the    component collection, the processor-executable instructions    structured as:    -   obtain, via at least one processor, equity's conditional beta        model training and test data sets, a set of rolling window        period lengths, and data sets for predicted conditional beta        through trained model on the same processor;    -   compute, via at least one processor, for each equity, the        residual correlation between the predicted beta and residuals of        prediction, the residual normal p value, the residual effective        size, the residual Mann Whitney U value, and the residual        standard deviation; and    -   validate, via at least one processor, from a set of residual        analysis matrix, that beta residuals from models are unbiased,        that beta residuals from models are substantively close to zero.        4. A machine learning equity idiosyncratic risk model apparatus,        comprising:-   a memory;-   a component collection in the memory;-   a processor disposed in communication with the memory and configured    to issue a plurality of processor-executable instructions from the    component collection, the processor-executable instructions    structured as:    -   obtain, via at least one processor, equity's historical        idiosyncratic risk data sets, a set of rolling window period        lengths, data sets for the set of market factors' historical        returns during the specified rolling window periods, and data        sets for the set of company specific financials factors'        historical values during the specified rolling window periods;    -   compute, via at least one processor, for each equity, during        each rolling window period from the set of rolling window        periods, with the set of features contributing to a positive        gain in feature importance ranking and contributing to a        positive gain in adjusted R square, the weighted sum squared        Euclidean distance between each simulated market scenario and        each historical scenario; and    -   select, via at least one processor, for each equity, during each        rolling window period from the set of rolling window periods,        the closest historical scenario to simulated market scenarios,        and assign the stored idiosyncratic risk of this historical        scenario to this simulated market scenario.        5. The apparatus of embodiment 1, further, comprising:-   Spark analyzes computation tasks and optimize the workflow of the    data processing before actually executing the code, which makes it    outperforms Hadoop in terms of performance with Directed Acyclic    Graph (DAG) optimizations and in memory processing.    6. The apparatus of embodiment 5, further, comprising:    -   use EMR Notebooks along with EMR clusters to submit Spark jobs        for parallel computing to improve the development efficiency.        7. The apparatus of embodiment 6, further, comprising:-   EMR to make full usage of compute power offered by the cloud    provider and save compute costs, since the EMR runtime for Spark can    be over 3 times faster than standard Spark.    8. The apparatus of embodiment 7, further, comprising:-   EMR Notebook provides following functionalities and characteristics:-   support multiple programming languages;-   test and debug code interactively;-   monitor Spark activity from within the notebook;-   visualize large datasets and resuming at broken steps; and-   detach and attach a notebook to different EMR clusters easily.    9. The apparatus of embodiment 8, further, comprising:-   the workflow of parallel computing of a single task of asset    simulation with EMR Notebook comprising:    -   create an EMR cluster with a predefined bootstrap script        including all the dependencies required by a service;    -   execute the bootstrap script on each worker node in the cluster        script to have dependent libraries installed;    -   create an EMR Notebook with a pre-defined service IAM role and        connect it to the EMR cluster;    -   load input data into EMR cluster and store among the core nodes        in a distributed way once the EMR cluster is in ready status;    -   group assets by the asset id and apply Spark mapper and reducer        functions on each asset to conduct a series of transformations        and reductions; and    -   save the eventual results, such as trained model in the format        of binary or predicted scores by the model into Postgres        database after the transformations are finished.        10. The apparatus of embodiment 1, further, comprising:-   A big data and machine learning self-service computation platform,    comprising:-   a Workflow Declaration Language (WDL);-   an implementation of the WDL;-   a collection of components in the WDL structured as:    -   provision an event-driven, self-service, and extensible        computation engine.        11. The apparatus of embodiment 1, further, comprising:-   the executable instructions structured as:    -   declaratively define the desired state of big data and machine        learning pipelines;    -   programmatically transform the desired state into workflow;    -   automatically generate workflow code for resource provision, job        submission, job scheduling, job monitoring and Job dependency        orchestration; and    -   automatically inject the workflow into a container for        scheduling and execution.        12. The apparatus of embodiment 1, further, comprising:-   a plurality of platform-executable jobs derived from big data and    machine learning artifacts, structured as:    -   execute on a variety of platforms and services with desired or        elastic capacity: multi-node clusters, virtual servers,        containers and lambda functions.        13. The apparatus of embodiment 1, further, comprising:-   an event-driven architecture with loosely coupled event producers    and consumers, integrated to:    -   fulfil the prescription of resource allocation;    -   generate workflow code to facilitate self-service;    -   provision vertical and horizontal scalability; and    -   support fault-tolerance.        14. The apparatus of embodiment 1, further, comprising:-   parallel on parallel hierarchy and flexible calculation    dependencies, structured as:    -   enable multiple jobs to be concurrently distributed to multiple        nodes with tasks in each job executed in parallel.        15. The apparatus of embodiment 1, further, comprising:-   heterogenous platforms consists of EMR, EC2, ECS and Lambda    functions;-   a set of supported languages: Scala, Java and Python;    16. The apparatus of embodiment 1, further, comprising:-   generic roles and responsibilities defined as interfaces for    functional implementation;-   open source technologies adopted to ensure cloud provider    agnosticism.    17. The apparatus of embodiment 1, further, comprising:-   an optimization with performance by using network-optimized,    memory-optimized and/or compute-optimized cloud instances based on    the nature of the computation.    18. The apparatus of embodiment 1, further, comprising:-   an optimization with cost leveraging:    -   inexpensive and commodity-grade virtual servers;    -   price-discount with Spot Instances or Reserved Instances.        19. The apparatus of embodiment 1, further, comprising:-   a unified, distributed, parallel, generic computation engine    supporting:    -   big data batch and streaming processing for financial data ETL        and simulation;    -   machine learning training and scoring for fixed income, equity        and mutual fund and ETF.        20. The apparatus of embodiment 1, further, comprising:-   the processor-executable instructions structured as:    -   apply big data framework, Spark, with EMR and EMR Notebook, to        support the data process and storage in a parallel and        distributed way.

Optimized Portfolio Generation Using Simulated or Realized Returns withLoss Tolerance or Return Volatility Controls, Generation of Mean-CVaRand Mean-Variance Frontiers with Parallel Computing

1. A Tail Risk Optimizer risk tool, comprising:

-   -   1. an optimization finding the optimal portfolio weights set        that reaches max return along with conditional Value at Risk        constraints and self-defined asset max allocation weights. The        optimization process is structured as:    -   2. define, via users' loss tolerance, a CVaR threshold        percentage that is allowed within the portfolio and self-defined        max allocation for each asset in the portfolio, and;    -   3. obtain, via at least one processor, assets' simulated returns        data sets, a set of return data of each asset with different        market scenarios, to:    -   4. convert, via CVaR linear relaxation, the convex CVaR        calculation into a linear system to accelerate the optimizer;        with an introduction of some auxiliary variable to discretize        the integral in general CVaR computation process;    -   5. optimize; via mixed integer programming techniques; the        portfolio expected return with specified asset max allocation,        CVaR threshold and allowed volume of cash holdings; acquire, via        parallel computation, a proposed set of portfolio weights and        its expected return/volatility/drawdown; taking advantages of        compute power provided by cloud platform and applies AWS Elastic        Container Service (ECS) which is a fully managed container        orchestration service to handle requests in a parallel way.        Multiple user requests are loaded into different containers that        are hosted on a cluster of EC2 machines. Within a single        request, the computation process of CVAR is distributed among        different CPU cores in each container using multiprocessing        mechanism. By using parallel computing techniques, ECS and        multiprocessing, the service performance is significantly        improved.    -   6. visualize, via CVaR-Mean frontier plot consisting of hundreds        of optimal portfolio points with current constraints but        different CVaR threshold, portfolio return versus portfolio        CVaR; the relative position between the current optimal        portfolio and initial portfolio. Allowing changes of scenarios,        business cycles or optimization types, the CVaR-Mean frontier to        change accordingly and the capacity of comparing optimal        portfolios under different scenarios and methodologies.        2. A Mean Variance Optimizer risk tool, comprising:    -   1. an optimization finding the best balance between expected        return and portfolio risk according to a user specified risk        tolerance level and self-defined asset max allocation weights.        The optimization process is structured as:    -   2. define, via users' preference, a risk tolerance level ranging        from 0 to 10 as risk averse situation to risk seeking situation,        corresponding to conservative investors to aggressive investors        and;    -   3. obtain, via at least one processor, assets' simulated returns        data sets, a set of return data of each asset with different        market scenarios, to:    -   4. estimate, via Ledoit-Wolf covariance matrix estimation method        which corrects both bias and variance of sample covariance        matrix or; historical-based covariance matrix estimation method        with addition of a small number on the diagonal to decorrelate        asset behavior to capture accurate and robust portfolio risk;    -   5. optimize; via objective function of maximizing sum of the        portfolio return and a risk penalty with coefficient as risk        tolerance parameter; along with the constraints of specified        asset max allocation as well as the integrity of portfolio        weights summation; acquire, via parallel computation, a proposed        set of portfolio weights and its expected        return/volatility/drawdown; taking advantages of compute power        provided by cloud platform and applies AWS Elastic Container        Service (ECS) which is a fully managed container orchestration        service to handle requests in a parallel way. Multiple user        requests are loaded into different containers that are hosted on        a cluster of EC2 machines. Within a single request, the        computation process of CVAR is distributed among different CPU        cores in each container using multiprocessing mechanism. By        using parallel computing techniques, ECS and multiprocessing,        the service performance is significantly improved.    -   6. visualize, via efficient frontier (Volatility-Mean) plot        consisting of around 1700 optimal portfolio points with current        constraints but different risk tolerance level, portfolio return        versus portfolio risk; the relative position between the current        optimal portfolio and initial portfolio. Allowing changes of        scenarios, business cycles or optimization types, the efficient        frontier to change accordingly and the capacity of comparing        optimal portfolios under different scenarios and methodologies.

Constructing Predefined Scenarios (GUI) Using Simulated Market Scenariosand Scenario-Based Risk Reporting Using Multiple User-Defined Scenarios

-   1. A computer program or application comprising a volatile or    non-volatile computer usable medium having executable code to    execute a process for generating scenario-based risk reporting for    multiple user-specified scenarios, the process comprising:-   obtain, on all available processors, for all securities, load asset    simulation data in temporary storage or memory based on time-horizon    selected by the user, input passed to the process as a data    structure; input data structure includes user-specified scenarios;    generate asset simulation data if not available; load call and put    schedule in temporary storage or memory to be used by alternate    asset simulation process;-   simulate, as alternate asset simulation process, on all available    processors, for all securities, calculate the dot product of factor    exposure for selected securities and factor simulations; adjust    simulated returns for assets based on call and put schedule;-   generate, on all available processors, for all available    user-defined scenarios, find markets matching user provided    criteria; apply multiple criteria as provided in user input; store    list of markets in a map data structure in temporary storage or    memory;-   calculate, on all available processors, for all available    user-defined scenarios from the map, get market returns based on    markets in the map entry; calculate weighted average market returns    using asset simulation returns and security weights; store market    returns to the map;-   compute, as main process, on all available processors, for all    available user-defined scenarios from the map, use the market    returns stored in the map to calculate tail-risk and other    risk-based analytics; and-   visualize real-time, via at least one processor, for each portfolio,    for each rolling window period from the set of rolling window    periods, its simulated returns distributions under user-specified    market scenarios or business cycles (e.g., rising interest rates,    recession, etc.).

Fixed Income Securities Returns Simulation and Portfolio RiskAggregation Using Oracle RDS or Map Reduce Cloud Computing Technologies

-   1. A Database-Implemented Procedure for Multi-Risk Factor Risk    Engine Method Executed by One or More Processors, the Method    Comprising:-   obtain, a list of unique securities for which a main operation needs    to be executed based on user provided inputs for data filtering;-   filter, factor exposures data based on list of unique securities and    store in temporary storage or memory; Use Oracle RDS Global    Temporary Tables (GTT) to run batch in multiple sessions; further    filter, factor simulation data based on unique factors available    from factor exposure data and store in temporary storage or memory;    if factor exposure data not available, calculate factor exposure    data as alternate operation for current pricing date;-   process, the alternate operation, on all available processors,    calculate spread ratio for all securities using dimension reduction;    store calculated factor exposure in local storage or memory; Use    Global Temporary Tables where needed for temporary storage;-   process, the main operation, all available unique securities in    small chunks or batches, for each batch;-   retrieve, from temporary storage or memory, the necessary factor    simulation and factor exposure data relevant to the unique    securities within the batch;-   execute, for all available processors, in parallel, for each    security within the batch, the sum product of factor exposure and    factor simulations for each security and store result asset    simulation data in temporary storage or memory; Use combination of    Oracle's Parallel Queries and Global Temporary Tables to parallelize    computations;-   calibrate, for all available processors, in parallel, the asset    simulated returns for each security, based on call and put schedule    data available for each security;-   transpose, from temporary storage or memory, retrieve the asset    simulation data for each security within the batch and transpose    data from individual records to a list-based data structure and    store results to permanent storage in database; Use of Oracle's DDL    commands for faster cleanup of Global Temporary Tables (GTT).-   Adding the carry return of fixed income instruments based on    estimated maturity date. Such that if the security matures within    the simulated investment time horizon, the yield to the estimated    maturity date is used to represent the carry return.-   Adjusting the call and put schedules by not allowing the simulated    price returns to go beyond the call or put prices if the call and    put schedules fall in the simulation time horizon.-   Adjusting for default probabilities by ensuring the simulated    returns represent loss given default given the conditional default    flag for the instrument under the different simulated markets.-   Adjusting for conditional spread beta in the price return    calculations given the conditional spread beta for the instrument    under the different simulated markets.-   Adjusting for convexity of the fixed income instruments in the    simulating of the price returns.-   2. The apparatus of embodiment 1, further, comprising:-   parallel on parallel hierarchy and flexible calculation    dependencies, structured as:    -   enable multiple jobs to be concurrently scheduled and executed        on Oracle RDS with tasks in each job executed in parallel.-   3. The apparatus of embodiment 1, further, comprising:-   ability to compute simulated returns for all time-horizons    simultaneously, structured as:    -   store calculated simulated return data as separate columns and        stored in temporary cache or storage;    -   transpose calculated simulated returns using PIVOT and UNPIVOT        Oracle commands to provide capability to compute simulated        returns simultaneously and storing data back to the database in        parallel.-   4. The apparatus of embodiment 1, further, comprising:-   Unique design to store simulated returns and market scenario id as a    single number. An array of such numbers is stored in storage medium    and transported between storage medium and API/UI layer. The unique    design ensured data compression, no need to encode/decode compressed    data and parallel portfolio risk aggregation for multiple market    scenarios, multiple time horizons and multiple portfolios    concurrently.    (e.g. <simulated_return>.<market_id> a single number: “−142.0153”    where −142 is the simulated return in bps and 153 is the market id.    This single dimensional array is a unique data format to support    aggregate portfolio simulated returns in parallel. This data format    eliminates the complexity to maintain mapping of the returns to    market scenarios. At the API layer, in processing this single    dimensional array in parallel, there is no need for    compression/decompression logic.)-   5. The apparatus of embodiment 1, further, comprising:-   heterogeneous platforms comprising: Oracle RDS on Cloud, Job    Scheduler and Lambda functions;-   a set of supported languages: PL-SQL, Java and Python.-   6. The apparatus of embodiment 1, further, comprising:-   an optimization with performance by using memory-optimized and/or    compute-optimized database instances based on the nature of the    computation.-   7. The apparatus of embodiment 1, further, comprising:-   Apply big data framework, Spark, with EMR and EMR Notebook, to    support the data process and storage in a parallel and distributed    way.-   8. The apparatus of embodiment 7, further, comprising:-   Spark analyzes computation tasks and optimize the workflow of the    data processing before actually executing the code, which makes it    outperforms Hadoop in terms of performance with Directed Acyclic    Graph (DAG) optimizations and in memory processing.-   9. The apparatus of embodiment 8, further, comprising:    -   use EMR Notebooks along with EMR clusters to submit Spark jobs        for parallel computing to improve the development efficiency.-   10. The apparatus of embodiment 9, further, comprising:-   EMR to make full usage of compute power offered by the cloud    provider and save compute costs, since the EMR runtime for Spark can    be over 3 times faster than standard Spark.-   11. The apparatus of embodiment 10, further, comprising:-   EMR Notebook provides following functionalities and characteristics:    support multiple programming languages; test and debug code    interactively; monitor Spark activity from within the notebook;    visualize large datasets and resuming at broken steps; and detach    and attach a notebook to different EMR clusters easily.-   12. The apparatus of embodiment 11, further, comprising:-   the workflow of parallel computing of a single task of asset    simulation with EMR Notebook comprising:    -   create an EMR cluster with a predefined bootstrap script        including all the dependencies required by a service;    -   execute the bootstrap script on each worker node in the cluster        script to have dependent libraries installed;    -   create an EMR Notebook with a pre-defined service IAM role and        connect it to the EMR cluster; load input data into EMR cluster        and store among the core nodes in a distributed way once the EMR        cluster is in ready status;    -   group assets by the asset id and apply Spark mapper and reducer        functions on each asset to conduct a series of transformations        and reductions;    -   save the eventual results, such as trained model in the format        of binary or predicted scores by the model into Postgres        database after the transformations are finished; and    -   calculate, for all available processors, in parallel, for each        security within the batch, sort available asset sims returns in        increasing order, take average of top five percent data and        store result to permanent storage in database; Use Parallel DML        to parallelize inserting records into the database.

Tail-Risk Adjusted Bond Ladder Construction

-   1. A computer program or application comprising a volatile or    non-volatile computer usable medium having executable code to    execute a process for constructing a bond ladder based on risk    adjusted yield, the process comprising:-   obtain, a list of available bond offerings available for trading    from various sources, based on filter criteria provided by the user,    the input provided in a data structure available to the program;-   retrieve, all analytics data related to available bonds, including    default probability, conditional value at risk (CVAR), yield, price,    available quantity to trade, etc.;-   calculate, on all available processors, mean and standard deviation,    for all bonds with default probability; calculate same for all bonds    with CVAR data; store computed mean and standard deviation in    temporary storage or memory;-   calculate, on all available processors, for all available bonds, the    z-score based on default probability of the bond, mean and standard    deviation of default probabilities of all bonds; For bonds with no    default probability, calculate z-score based on CVAR of the bond,    mean and standard deviation of CVAR for all bonds; adjusted yield    for the bond based on the computed z-score;-   sort, all available bonds based on adjusted yield, rating and    available quantity; group data in rungs based on maturity dates;-   process, as main operation, on all available processors, calculate    allocated value for all bonds within the rung; per bond based on    minimum increment, minimum denomination, diversification and minimum    balance remaining constraints; store residual cash not allocated per    rung into memory;-   compute, on all available processors, for all rungs, calculate    weighted average yield per rung; find rung with highest overall    yield;-   process, as final operation, on all available processors, calculate    allocated value for all bonds within the maximum yielding rung,    calculate allocated value per bond based on minimum increment,    minimum denomination, diversification and maximum balance remaining    constraints;-   visualize real-time, via at least one processor, for each portfolio,    display constructed bond ladder based on rungs as maturity year;    display portfolio level risk analytics;-   2. The apparatus of embodiment 1, further, comprising:-   the instructions to calculate in parallel, mean and standard    deviation based on default probability and CVaR for each rung    comprising instructions to:    -   generate, on all available processors; a map of all available        securities available in each rung that has a valid default        probability or CVaR; and    -   generate and store in parallel; on all available processors;        using temporary memory, a final computed values of mean and        standard deviation by rung number, from all available securities        in the map.-   3. The apparatus of embodiment 1, further, comprising:-   the instructions to calculate in parallel, the default probability    of securities based on maturity year for which the default    probabilities are not available comprising of instructions to:    -   determine, on all available processors; for all securities the        default probability of securities with missing data; using        default probabilities for available years; and    -   calculate, on all available processors, the default        probabilities using average of the prior and next year's default        probability.-   4. The apparatus of embodiment 1, further, comprising:-   the instructions to calculate the highest yielding run based on    weighted average calculations; structured as:    -   determine, on all available processors; for all available rungs,        securities that have quantities allocated; create a map for each        rung; and    -   calculate, on all available processors, the weighted average        yield for each rung using the yield of each security and weight        of the security based on market value for each rung.-   5. The apparatus of embodiment 1, further, comprising:-   the instructions to return additional securities available for the    user; for each rung based on highest available yield for each    security:    -   determine, on all available processors; for all available rungs;        sort and list additional bonds for all securities.-   6. The apparatus of embodiment 1, further, comprising:-   parallel on parallel hierarchy and flexible calculation    dependencies, structured as:    -   facilitate bond ladder construction to be executed in parallel        for each rung based on maturity date for the securities. The        allocation logic executes in parallel for each rung.-   7. The apparatus of embodiment 1, further, comprising:-   heterogenous platforms consists of ECS, Parallel Streams and Java    Web Caching;-   a set of supported languages: Docker scripts, Java.-   8. The apparatus of embodiment 1, further, comprising:-   an optimization with performance by using network-optimized,    memory-optimized and/or compute-optimized cloud instances based on    the nature of the computation.

Additional Embodiments

-   101. A machine learning portfolio generating apparatus, comprising:-   a memory;-   a component collection in the memory;-   a processor disposed in communication with the memory and configured    to issue a plurality of processor-executable instructions from the    component collection, the processor-executable instructions    structured as:    -   obtain, via at least one processor, a portfolio construction        request datastructure, the portfolio construction request        datastructure structured to include a set of optimization        parameters including a universe of securities, a time period        length, a conditional value at risk portion, a conditional value        at risk threshold, a portfolio value amount;    -   determine, via at least one processor, a set of simulated market        scenarios associated with the time period length, the set of        simulated market scenarios generated using a set of deep        learning neural networks, each simulated market scenario in the        set of simulated market scenarios structured to comprise a set        of simulated market factor values;    -   retrieve, via at least one processor, a set of expected returns        for securities in the universe of securities for the set of        simulated market scenarios, each expected return in the set of        expected returns configured as calculated for a security during        a simulated market scenario using:        -   the respective security's conditional Beta during the            respective simulated market scenario, determined using a set            of decision tree ensembles, trained to estimate conditional            Beta of the respective security, based on a first subset of            the set of simulated market factor values, and        -   the respective security's conditional default probability            during the respective simulated market scenario, determined            using a set of decision tree ensembles, trained to estimate            conditional default probability of the respective security,            based on a second subset of the set of simulated market            factor values;    -   optimize, via at least one processor, portfolio weights of        securities in the universe of securities in accordance with the        conditional value at risk portion, the conditional value at risk        threshold, and the portfolio value amount, using the set of        expected returns, to generate a set of tradeable transactions        that maximize expected portfolio return of an optimized        portfolio; and    -   execute, via at least one processor, the set of tradeable        transactions to generate the optimized portfolio.-   102. The apparatus of embodiment 101, further, comprising:-   the instructions to generate the set of simulated market scenarios    using the set of deep learning neural networks are structured to    comprise instructions to:    -   determine, via at least one processor, a set of historical        market scenarios and a set of time period buckets;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a subset of        historical market scenarios, from the set of historical market        scenarios, associated with the respective time period bucket;    -   train, via at least one processor, for each time period bucket        from the set of time period buckets, a deep learning neural        network, from the set of deep learning neural networks, using        the subset of historical market scenarios associated with the        respective time period bucket;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a number of        simulated market scenarios to generate using the trained deep        learning neural network associated with the respective time        period bucket; and    -   generate, via at least one processor, for each time period        bucket from the set of time period buckets, the determined        number of simulated market scenarios for the respective time        period bucket, using the trained deep learning neural network        associated with the respective time period bucket.-   103. The apparatus of embodiment 102, further, comprising:-   the instructions to determine the set of historical market scenarios    are structured to comprise instructions to:    -   determine, via at least one processor, a historical data set, a        rolling window period length, and a set of market factors;    -   determine, via at least one processor, a set of rolling window        periods using the historical data set and the rolling window        period length; and    -   calculate, via at least one processor, for each market factor        from the set of market factors, for each rolling window period        from the set of rolling window periods, a change to the        respective market factor during the respective rolling window        period,        -   each historical market scenario from the set of historical            market scenarios structured to comprise calculated changes            to the set of market factors during a rolling window period.-   104. The apparatus of embodiment 103, further, comprising:-   the instructions to calculate a change to a market factor during a    rolling window period are structured to comprise instructions to:    -   determine, via at least one processor, the delta between values        of the market factor at a beginning time point and an ending        time point of the rolling window period.-   105. The apparatus of embodiment 104, further, comprising:-   the processor-executable instructions structured as:    -   determine, via at least one processor, that historical data for        the market factor during the rolling window period is        unavailable for a time point; and    -   impute, via at least one processor, the unavailable historical        data for the time point using a machine learning method.-   106. The apparatus of embodiment 103, further, comprising:-   the rolling window period length is structured to be equal to the    time period length.-   107. The apparatus of embodiment 102, further, comprising:-   the set of time period buckets is structured to have an equal fixed    length for each time period bucket.-   108. The apparatus of embodiment 102, further, comprising:-   the set of time period buckets is structured to have a variable    length for each time period bucket, the variable length for each    time period bucket determined by judging the overall goodness of fit    between the set of simulated market scenarios and the set of    historical market scenarios.-   109. The apparatus of embodiment 102, further, comprising:-   the instructions to train a deep learning neural network for a time    period bucket using the associated subset of historical market    scenarios are structured to comprise instructions to:    -   select, via at least one processor, a historical market scenario        from the associated subset of historical market scenarios; and    -   train, via at least one processor, the deep learning neural        network for the time period bucket on the selected historical        market scenario using a variational autoencoder.-   110. The apparatus of embodiment 109, further, comprising:-   the deep learning neural network for the time period bucket is    trained to generate a set of Gaussian mixture latent variables.-   111. The apparatus of embodiment 110, further, comprising:-   the instructions to generate simulated market scenarios for the time    period bucket, using the trained deep learning neural network    associated with the time period bucket, are structured to comprise    instructions to:    -   generate, via at least one processor, a set of random values for        the set of Gaussian mixture latent variables; and    -   generate a simulated market scenario, from the simulated market        scenarios for the time period bucket, from the generated set of        random values using a neural network decoder of the trained deep        learning neural network associated with the time period bucket.-   112. The apparatus of embodiment 101, further, comprising:-   the processor-executable instructions structured as:    -   filter, via at least one processor, the set of simulated market        scenarios associated with the time period length based on        specified ranges of allowable values for specified customized        market factors.-   113. The apparatus of embodiment 101, further, comprising:-   the processor-executable instructions structured as:    -   filter, via at least one processor, the set of simulated market        scenarios associated with the time period length based on        specified business cycle settings.-   114. The apparatus of embodiment 101, further, comprising:-   the processor-executable instructions structured as:    -   initialize, via at least one processor, starting portfolio        weights of securities in the universe of securities to benchmark        portfolio weights of a benchmark portfolio.-   115. The apparatus of embodiment 101, further, comprising:-   the portfolio weights of securities in the universe of securities    are structured to be optimized by finding a mixed integer linear    programming portfolio solution.-   116. A machine learning portfolio generating processor-readable,    non-transient medium, comprising processor-executable instructions    structured as:    -   obtain, via at least one processor, a portfolio construction        request datastructure, the portfolio construction request        datastructure structured to include a set of optimization        parameters including a universe of securities, a time period        length, a conditional value at risk portion, a conditional value        at risk threshold, a portfolio value amount;    -   determine, via at least one processor, a set of simulated market        scenarios associated with the time period length, the set of        simulated market scenarios generated using a set of deep        learning neural networks, each simulated market scenario in the        set of simulated market scenarios structured to comprise a set        of simulated market factor values;    -   retrieve, via at least one processor, a set of expected returns        for securities in the universe of securities for the set of        simulated market scenarios, each expected return in the set of        expected returns configured as calculated for a security during        a simulated market scenario using:        -   the respective security's conditional Beta during the            respective simulated market scenario, determined using a set            of decision tree ensembles, trained to estimate conditional            Beta of the respective security, based on a first subset of            the set of simulated market factor values, and        -   the respective security's conditional default probability            during the respective simulated market scenario, determined            using a set of decision tree ensembles, trained to estimate            conditional default probability of the respective security,            based on a second subset of the set of simulated market            factor values;    -   optimize, via at least one processor, portfolio weights of        securities in the universe of securities in accordance with the        conditional value at risk portion, the conditional value at risk        threshold, and the portfolio value amount, using the set of        expected returns, to generate a set of tradeable transactions        that maximize expected portfolio return of an optimized        portfolio; and    -   execute, via at least one processor, the set of tradeable        transactions to generate the optimized portfolio.-   117. The medium of embodiment 116, further, comprising:-   the instructions to generate the set of simulated market scenarios    using the set of deep learning neural networks are structured to    comprise instructions to:    -   determine, via at least one processor, a set of historical        market scenarios and a set of time period buckets;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a subset of        historical market scenarios, from the set of historical market        scenarios, associated with the respective time period bucket;    -   train, via at least one processor, for each time period bucket        from the set of time period buckets, a deep learning neural        network, from the set of deep learning neural networks, using        the subset of historical market scenarios associated with the        respective time period bucket;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a number of        simulated market scenarios to generate using the trained deep        learning neural network associated with the respective time        period bucket; and    -   generate, via at least one processor, for each time period        bucket from the set of time period buckets, the determined        number of simulated market scenarios for the respective time        period bucket, using the trained deep learning neural network        associated with the respective time period bucket.-   118. The medium of embodiment 117, further, comprising:-   the instructions to determine the set of historical market scenarios    are structured to comprise instructions to:    -   determine, via at least one processor, a historical data set, a        rolling window period length, and a set of market factors;    -   determine, via at least one processor, a set of rolling window        periods using the historical data set and the rolling window        period length; and    -   calculate, via at least one processor, for each market factor        from the set of market factors, for each rolling window period        from the set of rolling window periods, a change to the        respective market factor during the respective rolling window        period,        -   each historical market scenario from the set of historical            market scenarios structured to comprise calculated changes            to the set of market factors during a rolling window period.-   119. The medium of embodiment 118, further, comprising:-   the instructions to calculate a change to a market factor during a    rolling window period are structured to comprise instructions to:    -   determine, via at least one processor, the delta between values        of the market factor at a beginning time point and an ending        time point of the rolling window period.-   120. The medium of embodiment 119, further, comprising:-   the processor-executable instructions structured as:    -   determine, via at least one processor, that historical data for        the market factor during the rolling window period is        unavailable for a time point; and    -   impute, via at least one processor, the unavailable historical        data for the time point using a machine learning method.-   121. The medium of embodiment 118, further, comprising:-   the rolling window period length is structured to be equal to the    time period length.-   122. The medium of embodiment 117, further, comprising:-   the set of time period buckets is structured to have an equal fixed    length for each time period bucket.-   123. The medium of embodiment 117, further, comprising:-   the set of time period buckets is structured to have a variable    length for each time period bucket, the variable length for each    time period bucket determined by judging the overall goodness of fit    between the set of simulated market scenarios and the set of    historical market scenarios.-   124. The medium of embodiment 117, further, comprising:-   the instructions to train a deep learning neural network for a time    period bucket using the associated subset of historical market    scenarios are structured to comprise instructions to:    -   select, via at least one processor, a historical market scenario        from the associated subset of historical market scenarios; and    -   train, via at least one processor, the deep learning neural        network for the time period bucket on the selected historical        market scenario using a variational autoencoder.-   125. The medium of embodiment 124, further, comprising:-   the deep learning neural network for the time period bucket is    trained to generate a set of Gaussian mixture latent variables.-   126. The medium of embodiment 125, further, comprising:-   the instructions to generate simulated market scenarios for the time    period bucket, using the trained deep learning neural network    associated with the time period bucket, are structured to comprise    instructions to:    -   generate, via at least one processor, a set of random values for        the set of Gaussian mixture latent variables; and    -   generate a simulated market scenario, from the simulated market        scenarios for the time period bucket, from the generated set of        random values using a neural network decoder of the trained deep        learning neural network associated with the time period bucket.-   127. The medium of embodiment 116, further, comprising:-   the processor-executable instructions structured as:    -   filter, via at least one processor, the set of simulated market        scenarios associated with the time period length based on        specified ranges of allowable values for specified customized        market factors.-   128. The medium of embodiment 116, further, comprising:-   the processor-executable instructions structured as:    -   filter, via at least one processor, the set of simulated market        scenarios associated with the time period length based on        specified business cycle settings.-   129. The medium of embodiment 116, further, comprising:-   the processor-executable instructions structured as:    -   initialize, via at least one processor, starting portfolio        weights of securities in the universe of securities to benchmark        portfolio weights of a benchmark portfolio.-   130. The medium of embodiment 116, further, comprising:-   the portfolio weights of securities in the universe of securities    are structured to be optimized by finding a mixed integer linear    programming portfolio solution.-   131. A machine learning portfolio generating processor-implemented    system, comprising:-   means to process processor-executable instructions;-   means to issue processor-issuable instructions from a    processor-executable component collection via the means to process    processor-executable instructions, the processor-issuable    instructions structured as:    -   obtain, via at least one processor, a portfolio construction        request datastructure, the portfolio construction request        datastructure structured to include a set of optimization        parameters including a universe of securities, a time period        length, a conditional value at risk portion, a conditional value        at risk threshold, a portfolio value amount;    -   determine, via at least one processor, a set of simulated market        scenarios associated with the time period length, the set of        simulated market scenarios generated using a set of deep        learning neural networks, each simulated market scenario in the        set of simulated market scenarios structured to comprise a set        of simulated market factor values;    -   retrieve, via at least one processor, a set of expected returns        for securities in the universe of securities for the set of        simulated market scenarios, each expected return in the set of        expected returns configured as calculated for a security during        a simulated market scenario using:        -   the respective security's conditional Beta during the            respective simulated market scenario, determined using a set            of decision tree ensembles, trained to estimate conditional            Beta of the respective security, based on a first subset of            the set of simulated market factor values, and        -   the respective security's conditional default probability            during the respective simulated market scenario, determined            using a set of decision tree ensembles, trained to estimate            conditional default probability of the respective security,            based on a second subset of the set of simulated market            factor values;    -   optimize, via at least one processor, portfolio weights of        securities in the universe of securities in accordance with the        conditional value at risk portion, the conditional value at risk        threshold, and the portfolio value amount, using the set of        expected returns, to generate a set of tradeable transactions        that maximize expected portfolio return of an optimized        portfolio; and    -   execute, via at least one processor, the set of tradeable        transactions to generate the optimized portfolio.-   132. The system of embodiment 131, further, comprising:-   the instructions to generate the set of simulated market scenarios    using the set of deep learning neural networks are structured to    comprise instructions to:    -   determine, via at least one processor, a set of historical        market scenarios and a set of time period buckets;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a subset of        historical market scenarios, from the set of historical market        scenarios, associated with the respective time period bucket;    -   train, via at least one processor, for each time period bucket        from the set of time period buckets, a deep learning neural        network, from the set of deep learning neural networks, using        the subset of historical market scenarios associated with the        respective time period bucket;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a number of        simulated market scenarios to generate using the trained deep        learning neural network associated with the respective time        period bucket; and    -   generate, via at least one processor, for each time period        bucket from the set of time period buckets, the determined        number of simulated market scenarios for the respective time        period bucket, using the trained deep learning neural network        associated with the respective time period bucket.-   133. The system of embodiment 132, further, comprising:-   the instructions to determine the set of historical market scenarios    are structured to comprise instructions to:    -   determine, via at least one processor, a historical data set, a        rolling window period length, and a set of market factors;    -   determine, via at least one processor, a set of rolling window        periods using the historical data set and the rolling window        period length; and    -   calculate, via at least one processor, for each market factor        from the set of market factors, for each rolling window period        from the set of rolling window periods, a change to the        respective market factor during the respective rolling window        period,        -   each historical market scenario from the set of historical            market scenarios structured to comprise calculated changes            to the set of market factors during a rolling window period.-   134. The system of embodiment 133, further, comprising:-   the instructions to calculate a change to a market factor during a    rolling window period are structured to comprise instructions to:    -   determine, via at least one processor, the delta between values        of the market factor at a beginning time point and an ending        time point of the rolling window period.-   135. The system of embodiment 134, further, comprising:-   the processor-executable instructions structured as:    -   determine, via at least one processor, that historical data for        the market factor during the rolling window period is        unavailable for a time point; and    -   impute, via at least one processor, the unavailable historical        data for the time point using a machine learning method.-   136. The system of embodiment 133, further, comprising:-   the rolling window period length is structured to be equal to the    time period length.-   137. The system of embodiment 132, further, comprising:-   the set of time period buckets is structured to have an equal fixed    length for each time period bucket.-   138. The system of embodiment 132, further, comprising:-   the set of time period buckets is structured to have a variable    length for each time period bucket, the variable length for each    time period bucket determined by judging the overall goodness of fit    between the set of simulated market scenarios and the set of    historical market scenarios.-   139. The system of embodiment 132, further, comprising:-   the instructions to train a deep learning neural network for a time    period bucket using the associated subset of historical market    scenarios are structured to comprise instructions to:    -   select, via at least one processor, a historical market scenario        from the associated subset of historical market scenarios; and    -   train, via at least one processor, the deep learning neural        network for the time period bucket on the selected historical        market scenario using a variational autoencoder.-   140. The system of embodiment 139, further, comprising:-   the deep learning neural network for the time period bucket is    trained to generate a set of Gaussian mixture latent variables.-   141. The system of embodiment 140, further, comprising:-   the instructions to generate simulated market scenarios for the time    period bucket, using the trained deep learning neural network    associated with the time period bucket, are structured to comprise    instructions to:    -   generate, via at least one processor, a set of random values for        the set of Gaussian mixture latent variables; and    -   generate a simulated market scenario, from the simulated market        scenarios for the time period bucket, from the generated set of        random values using a neural network decoder of the trained deep        learning neural network associated with the time period bucket.-   142. The system of embodiment 131, further, comprising:-   the processor-executable instructions structured as:    -   filter, via at least one processor, the set of simulated market        scenarios associated with the time period length based on        specified ranges of allowable values for specified customized        market factors.-   143. The system of embodiment 131, further, comprising:-   the processor-executable instructions structured as:    -   filter, via at least one processor, the set of simulated market        scenarios associated with the time period length based on        specified business cycle settings.-   144. The system of embodiment 131, further, comprising:-   the processor-executable instructions structured as:    -   initialize, via at least one processor, starting portfolio        weights of securities in the universe of securities to benchmark        portfolio weights of a benchmark portfolio.-   145. The system of embodiment 131, further, comprising:-   the portfolio weights of securities in the universe of securities    are structured to be optimized by finding a mixed integer linear    programming portfolio solution.-   146. A machine learning portfolio generating processor-implemented    process, comprising executing processor-executable instructions to:    -   obtain, via at least one processor, a portfolio construction        request datastructure, the portfolio construction request        datastructure structured to include a set of optimization        parameters including a universe of securities, a time period        length, a conditional value at risk portion, a conditional value        at risk threshold, a portfolio value amount;    -   determine, via at least one processor, a set of simulated market        scenarios associated with the time period length, the set of        simulated market scenarios generated using a set of deep        learning neural networks, each simulated market scenario in the        set of simulated market scenarios structured to comprise a set        of simulated market factor values;    -   retrieve, via at least one processor, a set of expected returns        for securities in the universe of securities for the set of        simulated market scenarios, each expected return in the set of        expected returns configured as calculated for a security during        a simulated market scenario using:        -   the respective security's conditional Beta during the            respective simulated market scenario, determined using a set            of decision tree ensembles, trained to estimate conditional            Beta of the respective security, based on a first subset of            the set of simulated market factor values, and        -   the respective security's conditional default probability            during the respective simulated market scenario, determined            using a set of decision tree ensembles, trained to estimate            conditional default probability of the respective security,            based on a second subset of the set of simulated market            factor values;    -   optimize, via at least one processor, portfolio weights of        securities in the universe of securities in accordance with the        conditional value at risk portion, the conditional value at risk        threshold, and the portfolio value amount, using the set of        expected returns, to generate a set of tradeable transactions        that maximize expected portfolio return of an optimized        portfolio; and    -   execute, via at least one processor, the set of tradeable        transactions to generate the optimized portfolio.-   147. The process of embodiment 146, further, comprising:-   the instructions to generate the set of simulated market scenarios    using the set of deep learning neural networks are structured to    comprise instructions to:    -   determine, via at least one processor, a set of historical        market scenarios and a set of time period buckets;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a subset of        historical market scenarios, from the set of historical market        scenarios, associated with the respective time period bucket;    -   train, via at least one processor, for each time period bucket        from the set of time period buckets, a deep learning neural        network, from the set of deep learning neural networks, using        the subset of historical market scenarios associated with the        respective time period bucket;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a number of        simulated market scenarios to generate using the trained deep        learning neural network associated with the respective time        period bucket; and    -   generate, via at least one processor, for each time period        bucket from the set of time period buckets, the determined        number of simulated market scenarios for the respective time        period bucket, using the trained deep learning neural network        associated with the respective time period bucket.-   148. The process of embodiment 147, further, comprising:-   the instructions to determine the set of historical market scenarios    are structured to comprise instructions to:    -   determine, via at least one processor, a historical data set, a        rolling window period length, and a set of market factors;    -   determine, via at least one processor, a set of rolling window        periods using the historical data set and the rolling window        period length; and    -   calculate, via at least one processor, for each market factor        from the set of market factors, for each rolling window period        from the set of rolling window periods, a change to the        respective market factor during the respective rolling window        period,        -   each historical market scenario from the set of historical            market scenarios structured to comprise calculated changes            to the set of market factors during a rolling window period.-   149. The process of embodiment 148, further, comprising:-   the instructions to calculate a change to a market factor during a    rolling window period are structured to comprise instructions to:    -   determine, via at least one processor, the delta between values        of the market factor at a beginning time point and an ending        time point of the rolling window period.-   150. The process of embodiment 149, further, comprising:-   the processor-executable instructions structured as:    -   determine, via at least one processor, that historical data for        the market factor during the rolling window period is        unavailable for a time point; and    -   impute, via at least one processor, the unavailable historical        data for the time point using a machine learning method.-   151. The process of embodiment 148, further, comprising:-   the rolling window period length is structured to be equal to the    time period length.-   152. The process of embodiment 147, further, comprising:-   the set of time period buckets is structured to have an equal fixed    length for each time period bucket.-   153. The process of embodiment 147, further, comprising:-   the set of time period buckets is structured to have a variable    length for each time period bucket, the variable length for each    time period bucket determined by judging the overall goodness of fit    between the set of simulated market scenarios and the set of    historical market scenarios.-   154. The process of embodiment 147, further, comprising:-   the instructions to train a deep learning neural network for a time    period bucket using the associated subset of historical market    scenarios are structured to comprise instructions to:    -   select, via at least one processor, a historical market scenario        from the associated subset of historical market scenarios; and    -   train, via at least one processor, the deep learning neural        network for the time period bucket on the selected historical        market scenario using a variational autoencoder.-   155. The process of embodiment 154, further, comprising:-   the deep learning neural network for the time period bucket is    trained to generate a set of Gaussian mixture latent variables.-   156. The process of embodiment 155, further, comprising:-   the instructions to generate simulated market scenarios for the time    period bucket, using the trained deep learning neural network    associated with the time period bucket, are structured to comprise    instructions to:    -   generate, via at least one processor, a set of random values for        the set of Gaussian mixture latent variables; and    -   generate a simulated market scenario, from the simulated market        scenarios for the time period bucket, from the generated set of        random values using a neural network decoder of the trained deep        learning neural network associated with the time period bucket.-   157. The process of embodiment 146, further, comprising:-   the processor-executable instructions structured as:    -   filter, via at least one processor, the set of simulated market        scenarios associated with the time period length based on        specified ranges of allowable values for specified customized        market factors.-   158. The process of embodiment 146, further, comprising:-   the processor-executable instructions structured as:    -   filter, via at least one processor, the set of simulated market        scenarios associated with the time period length based on        specified business cycle settings.-   159. The process of embodiment 146, further, comprising:-   the processor-executable instructions structured as:    -   initialize, via at least one processor, starting portfolio        weights of securities in the universe of securities to benchmark        portfolio weights of a benchmark portfolio.-   160. The process of embodiment 146, further, comprising:-   the portfolio weights of securities in the universe of securities    are structured to be optimized by finding a mixed integer linear    programming portfolio solution.-   201. A machine learning portfolio generating apparatus, comprising:-   a memory;-   a component collection in the memory;-   a processor disposed in communication with the memory and configured    to issue a plurality of processor-executable instructions from the    component collection, the processor-executable instructions    structured as:    -   obtain, via at least one processor, a portfolio construction        request datastructure, the portfolio construction request        datastructure structured to include a set of optimization        parameters including a universe of securities, a time period        length, a conditional value at risk portion, a conditional value        at risk threshold, a portfolio value amount;    -   determine, via at least one processor, a set of simulated market        scenarios associated with the time period length, the set of        simulated market scenarios generated using a set of        multi-variate mixture datastructures, each simulated market        scenario in the set of simulated market scenarios structured to        comprise a set of simulated market factor values;    -   retrieve, via at least one processor, a set of expected returns        for securities in the universe of securities for the set of        simulated market scenarios, each expected return in the set of        expected returns configured as calculated for a security during        a simulated market scenario using:        -   the respective security's conditional Beta during the            respective simulated market scenario, determined using a set            of decision tree ensembles, trained to estimate conditional            Beta of the respective security, based on a first subset of            the set of simulated market factor values, and        -   the respective security's conditional default probability            during the respective simulated market scenario, determined            using a set of decision tree ensembles, trained to estimate            conditional default probability of the respective security,            based on a second subset of the set of simulated market            factor values;    -   optimize, via at least one processor, portfolio weights of        securities in the universe of securities in accordance with the        conditional value at risk portion, the conditional value at risk        threshold, and the portfolio value amount, using the set of        expected returns, to generate a set of tradeable transactions        that maximize expected portfolio return of an optimized        portfolio; and    -   execute, via at least one processor, the set of tradeable        transactions to generate the optimized portfolio.-   202. The apparatus of embodiment 201, further, comprising:-   the instructions to generate the set of simulated market scenarios    using the set of multi-variate mixture datastructures are structured    to comprise instructions to    -   determine, via at least one processor, a set of historical        market scenarios and a set of time period buckets;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a subset of        historical market scenarios, from the set of historical market        scenarios, associated with the respective time period bucket;    -   train, via at least one processor, for each time period bucket        from the set of time period buckets, a multi-variate mixture        datastructure, from the set of multi-variate mixture        datastructures, using the subset of historical market scenarios        associated with the respective time period bucket;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a number of        simulated market scenarios to generate using the trained        multi-variate mixture datastructure associated with the        respective time period bucket; and    -   generate, via at least one processor, for each time period        bucket from the set of time period buckets, the determined        number of simulated market scenarios for the respective time        period bucket, using the trained multi-variate mixture        datastructure associated with the respective time period bucket.-   203. The apparatus of embodiment 202, further, comprising:-   the instructions to determine the set of historical market scenarios    are structured to comprise instructions to:    -   determine, via at least one processor, a historical data set and        a set of market factors;    -   determine, via at least one processor, a set of rolling window        periods for the historical data set; and    -   calculate, via at least one processor, for each market factor        from the set of market factors, for each rolling window period        from the set of rolling window periods, a change to the        respective market factor during the respective rolling window        period,    -   each historical market scenario from the set of historical        market scenarios structured to comprise calculated changes to        the set of market factors during a rolling window period.-   204. The apparatus of embodiment 203, further, comprising:-   the instructions to calculate a change to a market factor during a    rolling window period are structured to comprise instructions to:    -   determine, via at least one processor, the delta between values        of the market factor at two time point of the rolling window        period.-   205. The apparatus of embodiment 204, further, comprising:-   the processor-executable instructions structured as:    -   determine, via at least one processor, that historical data for        the market factor during the rolling window period is        unavailable for a time point; and    -   impute, via at least one processor, the unavailable historical        data for the time point using a k-Nearest Neighbors method.-   206. The apparatus of embodiment 203, further, comprising:-   the length of a rolling window period is structured to be equal to    the time period length.-   207. The apparatus of embodiment 202, further, comprising:-   the set of time period buckets is structured to have a fixed length    for each time period bucket.-   208. The apparatus of embodiment 202, further, comprising:-   the set of time period buckets is structured to have variable    lengths, the variable length for each time period bucket reflective    of changes in volatilities and correlations of the set of historical    market scenarios.-   209. The apparatus of embodiment 203, further, comprising:-   the instructions to train a multi-variate mixture datastructure for    a time period bucket using the associated subset of historical    market scenarios are structured to comprise instructions to:    -   determine, via at least one processor, for each market factor        from the set of market factors, a distribution to use for the        respective market factor for the time period bucket;    -   fit, via at least one processor, for each market factor from the        set of market factors, the distribution to use for the        respective market factor for the time period bucket using the        associated subset of historical market scenarios;    -   determine, via at least one processor, a copula for the set of        market factors for the time period bucket; and    -   train, via at least one processor, the multi-variate mixture        datastructure for the time period bucket using the fitted        distributions and the copula for the set of market factors.-   210. The apparatus of embodiment 209, further, comprising:-   the instructions to fit the distribution to use for a market factor    for the time period bucket using the associated subset of historical    market scenarios are structured to comprise instructions to    calculate the mean of the market factor's values in the associated    subset of historical market scenarios.-   211. The apparatus of embodiment 202, further, comprising:-   the instructions to generate simulated market scenarios for a time    period bucket, using the trained multi-variate mixture datastructure    associated with the time period bucket, are structured to comprise    instructions to:    -   generate a simulated market scenario, from the simulated market        scenarios for the time period bucket, by sampling the trained        multi-variate mixture datastructure associated with the time        period bucket.-   212. The apparatus of embodiment 201, further, comprising:-   the processor-executable instructions structured as:    -   filter, via at least one processor, the set of simulated market        scenarios associated with the time period length based on        specified ranges of allowable values for specified customized        market factors.-   213. The apparatus of embodiment 201, further, comprising:-   the processor-executable instructions structured as:    -   filter, via at least one processor, the set of simulated market        scenarios associated with the time period length based on        specified business cycle settings.-   214. The apparatus of embodiment 201, further, comprising:-   the processor-executable instructions structured as:    -   initialize, via at least one processor, starting portfolio        weights of securities in the universe of securities to benchmark        portfolio weights of a benchmark portfolio.-   215. The apparatus of embodiment 201, further, comprising:-   the portfolio weights of securities in the universe of securities    are structured to be optimized by finding a mixed integer linear    programming portfolio solution.-   216. A machine learning portfolio generating processor-readable,    non-transient medium, comprising processor-executable instructions    structured as:    -   obtain, via at least one processor, a portfolio construction        request datastructure, the portfolio construction request        datastructure structured to include a set of optimization        parameters including a universe of securities, a time period        length, a conditional value at risk portion, a conditional value        at risk threshold, a portfolio value amount;    -   determine, via at least one processor, a set of simulated market        scenarios associated with the time period length, the set of        simulated market scenarios generated using a set of        multi-variate mixture datastructures, each simulated market        scenario in the set of simulated market scenarios structured to        comprise a set of simulated market factor values;    -   retrieve, via at least one processor, a set of expected returns        for securities in the universe of securities for the set of        simulated market scenarios, each expected return in the set of        expected returns configured as calculated for a security during        a simulated market scenario using:        -   the respective security's conditional Beta during the            respective simulated market scenario, determined using a set            of decision tree ensembles, trained to estimate conditional            Beta of the respective security, based on a first subset of            the set of simulated market factor values, and        -   the respective security's conditional default probability            during the respective simulated market scenario, determined            using a set of decision tree ensembles, trained to estimate            conditional default probability of the respective security,            based on a second subset of the set of simulated market            factor values;    -   optimize, via at least one processor, portfolio weights of        securities in the universe of securities in accordance with the        conditional value at risk portion, the conditional value at risk        threshold, and the portfolio value amount, using the set of        expected returns, to generate a set of tradeable transactions        that maximize expected portfolio return of an optimized        portfolio; and    -   execute, via at least one processor, the set of tradeable        transactions to generate the optimized portfolio.-   217. The medium of embodiment 216, further, comprising:-   the instructions to generate the set of simulated market scenarios    using the set of multi-variate mixture datastructures are structured    to comprise instructions to    -   determine, via at least one processor, a set of historical        market scenarios and a set of time period buckets;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a subset of        historical market scenarios, from the set of historical market        scenarios, associated with the respective time period bucket;    -   train, via at least one processor, for each time period bucket        from the set of time period buckets, a multi-variate mixture        datastructure, from the set of multi-variate mixture        datastructures, using the subset of historical market scenarios        associated with the respective time period bucket;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a number of        simulated market scenarios to generate using the trained        multi-variate mixture datastructure associated with the        respective time period bucket; and    -   generate, via at least one processor, for each time period        bucket from the set of time period buckets, the determined        number of simulated market scenarios for the respective time        period bucket, using the trained multi-variate mixture        datastructure associated with the respective time period bucket.-   218. The medium of embodiment 217, further, comprising:-   the instructions to determine the set of historical market scenarios    are structured to comprise instructions to:    -   determine, via at least one processor, a historical data set and        a set of market factors;    -   determine, via at least one processor, a set of rolling window        periods for the historical data set; and    -   calculate, via at least one processor, for each market factor        from the set of market factors, for each rolling window period        from the set of rolling window periods, a change to the        respective market factor during the respective rolling window        period,        -   each historical market scenario from the set of historical            market scenarios structured to comprise calculated changes            to the set of market factors during a rolling window period.-   219. The medium of embodiment 218, further, comprising:-   the instructions to calculate a change to a market factor during a    rolling window period are structured to comprise instructions to:    -   determine, via at least one processor, the delta between values        of the market factor at two time point of the rolling window        period.-   220. The medium of embodiment 219, further, comprising:-   the processor-executable instructions structured as:    -   determine, via at least one processor, that historical data for        the market factor during the rolling window period is        unavailable for a time point; and    -   impute, via at least one processor, the unavailable historical        data for the time point using a k-Nearest Neighbors method.-   221. The medium of embodiment 218, further, comprising:-   the length of a rolling window period is structured to be equal to    the time period length.-   222. The medium of embodiment 217, further, comprising:-   the set of time period buckets is structured to have a fixed length    for each time period bucket.-   223. The medium of embodiment 217, further, comprising:-   the set of time period buckets is structured to have variable    lengths, the variable length for each time period bucket reflective    of changes in volatilities and correlations of the set of historical    market scenarios.-   224. The medium of embodiment 218, further, comprising:-   the instructions to train a multi-variate mixture datastructure for    a time period bucket using the associated subset of historical    market scenarios are structured to comprise instructions to:    -   determine, via at least one processor, for each market factor        from the set of market factors, a distribution to use for the        respective market factor for the time period bucket;    -   fit, via at least one processor, for each market factor from the        set of market factors, the distribution to use for the        respective market factor for the time period bucket using the        associated subset of historical market scenarios;    -   determine, via at least one processor, a copula for the set of        market factors for the time period bucket; and    -   train, via at least one processor, the multi-variate mixture        datastructure for the time period bucket using the fitted        distributions and the copula for the set of market factors.-   225. The medium of embodiment 224, further, comprising:-   the instructions to fit the distribution to use for a market factor    for the time period bucket using the associated subset of historical    market scenarios are structured to comprise instructions to    calculate the mean of the market factor's values in the associated    subset of historical market scenarios.-   226. The medium of embodiment 217, further, comprising:-   the instructions to generate simulated market scenarios for a time    period bucket, using the trained multi-variate mixture datastructure    associated with the time period bucket, are structured to comprise    instructions to:    -   generate a simulated market scenario, from the simulated market        scenarios for the time period bucket, by sampling the trained        multi-variate mixture datastructure associated with the time        period bucket.-   227. The medium of embodiment 216, further, comprising:-   the processor-executable instructions structured as:    -   filter, via at least one processor, the set of simulated market        scenarios associated with the time period length based on        specified ranges of allowable values for specified customized        market factors.-   228. The medium of embodiment 216, further, comprising:-   the processor-executable instructions structured as:    -   filter, via at least one processor, the set of simulated market        scenarios associated with the time period length based on        specified business cycle settings.-   229. The medium of embodiment 216, further, comprising:-   the processor-executable instructions structured as:    -   initialize, via at least one processor, starting portfolio        weights of securities in the universe of securities to benchmark        portfolio weights of a benchmark portfolio.-   230. The medium of embodiment 216, further, comprising:-   the portfolio weights of securities in the universe of securities    are structured to be optimized by finding a mixed integer linear    programming portfolio solution.-   231. A machine learning portfolio generating processor-implemented    system, comprising: means to process processor-executable    instructions;-   means to issue processor-issuable instructions from a    processor-executable component collection via the means to process    processor-executable instructions, the processor-issuable    instructions structured as:    -   obtain, via at least one processor, a portfolio construction        request datastructure, the portfolio construction request        datastructure structured to include a set of optimization        parameters including a universe of securities, a time period        length, a conditional value at risk portion, a conditional value        at risk threshold, a portfolio value amount;    -   determine, via at least one processor, a set of simulated market        scenarios associated with the time period length, the set of        simulated market scenarios generated using a set of        multi-variate mixture datastructures, each simulated market        scenario in the set of simulated market scenarios structured to        comprise a set of simulated market factor values; retrieve, via        at least one processor, a set of expected returns for securities        in the universe of securities for the set of simulated market        scenarios, each expected return in the set of expected returns        configured as calculated for a security during a simulated        market scenario using:        -   the respective security's conditional Beta during the            respective simulated market scenario, determined using a set            of decision tree ensembles, trained to estimate conditional            Beta of the respective security, based on a first subset of            the set of simulated market factor values, and        -   the respective security's conditional default probability            during the respective simulated market scenario, determined            using a set of decision tree ensembles, trained to estimate            conditional default probability of the respective security,            based on a second subset of the set of simulated market            factor values;    -   optimize, via at least one processor, portfolio weights of        securities in the universe of securities in accordance with the        conditional value at risk portion, the conditional value at risk        threshold, and the portfolio value amount, using the set of        expected returns, to generate a set of tradeable transactions        that maximize expected portfolio return of an optimized        portfolio; and    -   execute, via at least one processor, the set of tradeable        transactions to generate the optimized portfolio.-   232. The system of embodiment 231, further, comprising:-   the instructions to generate the set of simulated market scenarios    using the set of multi-variate mixture datastructures are structured    to comprise instructions to    -   determine, via at least one processor, a set of historical        market scenarios and a set of time period buckets;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a subset of        historical market scenarios, from the set of historical market        scenarios, associated with the respective time period bucket;    -   train, via at least one processor, for each time period bucket        from the set of time period buckets, a multi-variate mixture        datastructure, from the set of multi-variate mixture        datastructures, using the subset of historical market scenarios        associated with the respective time period bucket;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a number of        simulated market scenarios to generate using the trained        multi-variate mixture datastructure associated with the        respective time period bucket; and    -   generate, via at least one processor, for each time period        bucket from the set of time period buckets, the determined        number of simulated market scenarios for the respective time        period bucket, using the trained multi-variate mixture        datastructure associated with the respective time period bucket.-   233. The system of embodiment 232, further, comprising:-   the instructions to determine the set of historical market scenarios    are structured to comprise instructions to:    -   determine, via at least one processor, a historical data set and        a set of market factors;    -   determine, via at least one processor, a set of rolling window        periods for the historical data set; and    -   calculate, via at least one processor, for each market factor        from the set of market factors, for each rolling window period        from the set of rolling window periods, a change to the        respective market factor during the respective rolling window        period,        -   each historical market scenario from the set of historical            market scenarios structured to comprise calculated changes            to the set of market factors during a rolling window period.-   234. The system of embodiment 233, further, comprising:-   the instructions to calculate a change to a market factor during a    rolling window period are structured to comprise instructions to:    -   determine, via at least one processor, the delta between values        of the market factor at two time point of the rolling window        period.-   235. The system of embodiment 234, further, comprising:-   the processor-executable instructions structured as:    -   determine, via at least one processor, that historical data for        the market factor during the rolling window period is        unavailable for a time point; and    -   impute, via at least one processor, the unavailable historical        data for the time point using a k-Nearest Neighbors method.-   236. The system of embodiment 233, further, comprising:-   the length of a rolling window period is structured to be equal to    the time period length.-   237. The system of embodiment 232, further, comprising:-   the set of time period buckets is structured to have a fixed length    for each time period bucket.-   238. The system of embodiment 232, further, comprising:-   the set of time period buckets is structured to have variable    lengths, the variable length for each time period bucket reflective    of changes in volatilities and correlations of the set of historical    market scenarios.-   239. The system of embodiment 233, further, comprising:-   the instructions to train a multi-variate mixture datastructure for    a time period bucket using the associated subset of historical    market scenarios are structured to comprise instructions to:    -   determine, via at least one processor, for each market factor        from the set of market factors, a distribution to use for the        respective market factor for the time period bucket;    -   fit, via at least one processor, for each market factor from the        set of market factors, the distribution to use for the        respective market factor for the time period bucket using the        associated subset of historical market scenarios;    -   determine, via at least one processor, a copula for the set of        market factors for the time period bucket; and    -   train, via at least one processor, the multi-variate mixture        datastructure for the time period bucket using the fitted        distributions and the copula for the set of market factors.-   240. The system of embodiment 239, further, comprising:-   the instructions to fit the distribution to use for a market factor    for the time period bucket using the associated subset of historical    market scenarios are structured to comprise instructions to    calculate the mean of the market factor's values in the associated    subset of historical market scenarios.-   241. The system of embodiment 232, further, comprising:-   the instructions to generate simulated market scenarios for a time    period bucket, using the trained multi-variate mixture datastructure    associated with the time period bucket, are structured to comprise    instructions to:    -   generate a simulated market scenario, from the simulated market        scenarios for the time period bucket, by sampling the trained        multi-variate mixture datastructure associated with the time        period bucket.-   242. The system of embodiment 231, further, comprising:-   the processor-executable instructions structured as:    -   filter, via at least one processor, the set of simulated market        scenarios associated with the time period length based on        specified ranges of allowable values for specified customized        market factors.-   243. The system of embodiment 231, further, comprising:-   the processor-executable instructions structured as:    -   filter, via at least one processor, the set of simulated market        scenarios associated with the time period length based on        specified business cycle settings.-   244. The system of embodiment 231, further, comprising:-   the processor-executable instructions structured as:    -   initialize, via at least one processor, starting portfolio        weights of securities in the universe of securities to benchmark        portfolio weights of a benchmark portfolio.-   245. The system of embodiment 231, further, comprising:-   the portfolio weights of securities in the universe of securities    are structured to be optimized by finding a mixed integer linear    programming portfolio solution.-   246. A machine learning portfolio generating processor-implemented    process, comprising executing processor-executable instructions to:    -   obtain, via at least one processor, a portfolio construction        request datastructure, the portfolio construction request        datastructure structured to include a set of optimization        parameters including a universe of securities, a time period        length, a conditional value at risk portion, a conditional value        at risk threshold, a portfolio value amount;    -   determine, via at least one processor, a set of simulated market        scenarios associated with the time period length, the set of        simulated market scenarios generated using a set of        multi-variate mixture datastructures, each simulated market        scenario in the set of simulated market scenarios structured to        comprise a set of simulated market factor values;    -   retrieve, via at least one processor, a set of expected returns        for securities in the universe of securities for the set of        simulated market scenarios, each expected return in the set of        expected returns configured as calculated for a security during        a simulated market scenario using:        -   the respective security's conditional Beta during the            respective simulated market scenario, determined using a set            of decision tree ensembles, trained to estimate conditional            Beta of the respective security, based on a first subset of            the set of simulated market factor values, and        -   the respective security's conditional default probability            during the respective simulated market scenario, determined            using a set of decision tree ensembles, trained to estimate            conditional default probability of the respective security,            based on a second subset of the set of simulated market            factor values;    -   optimize, via at least one processor, portfolio weights of        securities in the universe of securities in accordance with the        conditional value at risk portion, the conditional value at risk        threshold, and the portfolio value amount, using the set of        expected returns, to generate a set of tradeable transactions        that maximize expected portfolio return of an optimized        portfolio; and    -   execute, via at least one processor, the set of tradeable        transactions to generate the optimized portfolio.-   247. The process of embodiment 246, further, comprising:-   the instructions to generate the set of simulated market scenarios    using the set of multi-variate mixture datastructures are structured    to comprise instructions to    -   determine, via at least one processor, a set of historical        market scenarios and a set of time period buckets;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a subset of        historical market scenarios, from the set of historical market        scenarios, associated with the respective time period bucket;    -   train, via at least one processor, for each time period bucket        from the set of time period buckets, a multi-variate mixture        datastructure, from the set of multi-variate mixture        datastructures, using the subset of historical market scenarios        associated with the respective time period bucket;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a number of        simulated market scenarios to generate using the trained        multi-variate mixture datastructure associated with the        respective time period bucket; and    -   generate, via at least one processor, for each time period        bucket from the set of time period buckets, the determined        number of simulated market scenarios for the respective time        period bucket, using the trained multi-variate mixture        datastructure associated with the respective time period bucket.-   248. The process of embodiment 247, further, comprising:-   the instructions to determine the set of historical market scenarios    are structured to comprise instructions to:    -   determine, via at least one processor, a historical data set and        a set of market factors;    -   determine, via at least one processor, a set of rolling window        periods for the historical data set; and    -   calculate, via at least one processor, for each market factor        from the set of market factors, for each rolling window period        from the set of rolling window periods, a change to the        respective market factor during the respective rolling window        period,        -   each historical market scenario from the set of historical            market scenarios structured to comprise calculated changes            to the set of market factors during a rolling window period.-   249. The process of embodiment 248, further, comprising:-   the instructions to calculate a change to a market factor during a    rolling window period are structured to comprise instructions to:    -   determine, via at least one processor, the delta between values        of the market factor at two time point of the rolling window        period.-   250. The process of embodiment 249, further, comprising:-   the processor-executable instructions structured as:    -   determine, via at least one processor, that historical data for        the market factor during the rolling window period is        unavailable for a time point; and    -   impute, via at least one processor, the unavailable historical        data for the time point using a k-Nearest Neighbors method.-   251. The process of embodiment 248, further, comprising:-   the length of a rolling window period is structured to be equal to    the time period length.-   252. The process of embodiment 247, further, comprising:-   the set of time period buckets is structured to have a fixed length    for each time period bucket.-   253. The process of embodiment 247, further, comprising:-   the set of time period buckets is structured to have variable    lengths, the variable length for each time period bucket reflective    of changes in volatilities and correlations of the set of historical    market scenarios.-   254. The process of embodiment 248, further, comprising:-   the instructions to train a multi-variate mixture datastructure for    a time period bucket using the associated subset of historical    market scenarios are structured to comprise instructions to:    -   determine, via at least one processor, for each market factor        from the set of market factors, a distribution to use for the        respective market factor for the time period bucket;    -   fit, via at least one processor, for each market factor from the        set of market factors, the distribution to use for the        respective market factor for the time period bucket using the        associated subset of historical market scenarios;    -   determine, via at least one processor, a copula for the set of        market factors for the time period bucket; and    -   train, via at least one processor, the multi-variate mixture        datastructure for the time period bucket using the fitted        distributions and the copula for the set of market factors.-   255. The process of embodiment 254, further, comprising:-   the instructions to fit the distribution to use for a market factor    for the time period bucket using the associated subset of historical    market scenarios are structured to comprise instructions to    calculate the mean of the market factor's values in the associated    subset of historical market scenarios.-   256. The process of embodiment 247, further, comprising:-   the instructions to generate simulated market scenarios for a time    period bucket, using the trained multi-variate mixture datastructure    associated with the time period bucket, are structured to comprise    instructions to:    -   generate a simulated market scenario, from the simulated market        scenarios for the time period bucket, by sampling the trained        multi-variate mixture datastructure associated with the time        period bucket.-   257. The process of embodiment 246, further, comprising:-   the processor-executable instructions structured as:    -   filter, via at least one processor, the set of simulated market        scenarios associated with the time period length based on        specified ranges of allowable values for specified customized        market factors.-   258. The process of embodiment 246, further, comprising:-   the processor-executable instructions structured as:    -   filter, via at least one processor, the set of simulated market        scenarios associated with the time period length based on        specified business cycle settings.-   259. The process of embodiment 246, further, comprising:-   the processor-executable instructions structured as:    -   initialize, via at least one processor, starting portfolio        weights of securities in the universe of securities to benchmark        portfolio weights of a benchmark portfolio.-   260. The process of embodiment 246, further, comprising:-   the portfolio weights of securities in the universe of securities    are structured to be optimized by finding a mixed integer linear    programming portfolio solution.-   301. A machine learning predefined scenario constructing apparatus,    comprising:-   a memory;-   a component collection in the memory;-   a processor disposed in communication with the memory and configured    to issue a plurality of processor-executable instructions from the    component collection, the processor-executable instructions    structured as:    -   obtain, via at least one processor, a user selection of a set of        simulated market scenarios via a simulation selection        interaction-interface mechanism, the set of simulated market        scenarios generated using a set of deep learning neural        networks, each simulated market scenario in the set of simulated        market scenarios structured to comprise a set of simulated        market factor values corresponding to a set of market factors;    -   determine, via at least one processor, a range of unfiltered        simulated market factor values for each market factor from the        set of market factors, the range of unfiltered simulated market        factor values for a market factor structured to include a        minimum simulated market factor value and a maximum simulated        market factor value in the set of simulated market scenarios for        the respective market factor;    -   generate, via at least one processor, a set of market factor        interaction-interface mechanisms, each market factor        interaction-interface mechanism in the set of market factor        interaction-interface mechanisms structured to be associated        with a market factor from the set of market factors and        structured to display the range of unfiltered simulated market        factor values for the respective market factor;    -   obtain, via at least one processor, a user modification to a        range of allowable values of a market factor from the set of        market factors via the market factor interaction-interface        mechanism associated with the modified market factor;    -   update, via at least one processor, a set of customized market        factors from the set of market factors based on the user        modification;    -   determine, via at least one processor, a range of allowable        values for each customized market factor from the set of        customized market factors;    -   filter, via at least one processor, the set of simulated market        scenarios based on the determined ranges of allowable values for        the set of customized market factors to determine a set of        filtered simulated market scenarios having simulated market        factor values that fall within the range of allowable values for        each customized market factors from the set of customized market        factors;    -   determine, via at least one processor, a range of filtered        simulated market factor values for each market factor from the        set of market factors, the range of filtered simulated market        factor values for a market factor structured to include a        minimum simulated market factor value and a maximum simulated        market factor value in the set of filtered simulated market        scenarios for the respective market factor; and    -   generate, via at least one processor, an updated set of market        factor interaction-interface mechanisms, each updated market        factor interaction-interface mechanism in the set of updated        market factor interaction-interface mechanisms structured to be        associated with a market factor from the set of market factors        and structured to display the range of filtered simulated market        factor values for the respective market factor.-   302. The apparatus of embodiment 301, further, comprising:-   the instructions to generate the set of simulated market scenarios    using the set of deep learning neural networks are structured to    comprise instructions to:    -   determine, via at least one processor, a set of historical        market scenarios and a set of time period buckets;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a subset of        historical market scenarios, from the set of historical market        scenarios, associated with the respective time period bucket;    -   train, via at least one processor, for each time period bucket        from the set of time period buckets, a deep learning neural        network, from the set of deep learning neural networks, using        the subset of historical market scenarios associated with the        respective time period bucket;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a number of        simulated market scenarios to generate using the trained deep        learning neural network associated with the respective time        period bucket; and    -   generate, via at least one processor, for each time period        bucket from the set of time period buckets, the determined        number of simulated market scenarios for the respective time        period bucket, using the trained deep learning neural network        associated with the respective time period bucket.-   303. The apparatus of embodiment 302, further, comprising:-   the instructions to determine the set of historical market scenarios    are structured to comprise instructions to:    -   determine, via at least one processor, a historical data set, a        rolling window period length, and the set of market factors;    -   determine, via at least one processor, a set of rolling window        periods using the historical data set and the rolling window        period length; and    -   calculate, via at least one processor, for each market factor        from the set of market factors, for each rolling window period        from the set of rolling window periods, a change to the        respective market factor during the respective rolling window        period,        -   each historical market scenario from the set of historical            market scenarios structured to comprise calculated changes            to the set of market factors during a rolling window period.-   304. The apparatus of embodiment 303, further, comprising:-   the instructions to calculate a change to a market factor during a    rolling window period are structured to comprise instructions to:    -   determine, via at least one processor, the delta between values        of the market factor at a beginning time point and an ending        time point of the rolling window period.-   305. The apparatus of embodiment 304, further, comprising:-   the processor-executable instructions structured as:    -   determine, via at least one processor, that historical data for        the market factor during the rolling window period is        unavailable for a time point; and    -   impute, via at least one processor, the unavailable historical        data for the time point using a machine learning method.-   306. The apparatus of embodiment 303, further, comprising:-   the rolling window period length is structured to be equal to the    time period length.-   307. The apparatus of embodiment 302, further, comprising:-   the set of time period buckets is structured to have an equal fixed    length for each time period bucket.-   308. The apparatus of embodiment 302, further, comprising:-   the set of time period buckets is structured to have a variable    length for each time period bucket, the variable length for each    time period bucket determined by judging the overall goodness of fit    between the set of simulated market scenarios and the set of    historical market scenarios.-   309. The apparatus of embodiment 302, further, comprising:-   the instructions to train a deep learning neural network for a time    period bucket using the associated subset of historical market    scenarios are structured to comprise instructions to:    -   select, via at least one processor, a historical market scenario        from the associated subset of historical market scenarios; and    -   train, via at least one processor, the deep learning neural        network for the time period bucket on the selected historical        market scenario using a variational autoencoder.-   310. The apparatus of embodiment 309, further, comprising:-   the deep learning neural network for the time period bucket is    trained to generate a set of Gaussian mixture latent variables.-   311. The apparatus of embodiment 310, further, comprising:-   the instructions to generate simulated market scenarios for the time    period bucket, using the trained deep learning neural network    associated with the time period bucket, are structured to comprise    instructions to:    -   generate, via at least one processor, a set of random values for        the set of Gaussian mixture latent variables; and    -   generate a simulated market scenario, from the simulated market        scenarios for the time period bucket, from the generated set of        random values using a neural network decoder of the trained deep        learning neural network associated with the time period bucket.-   312. The apparatus of embodiment 301, further, comprising:-   the simulation selection interaction-interface mechanism is    structured to comprise a pricing date selection    interaction-interface mechanism and a simulation model selection    interaction-interface mechanism.-   313. The apparatus of embodiment 301, further, comprising:-   the range of unfiltered simulated market factor values for a market    factor structured to include an average simulated market factor    value in the set of simulated market scenarios for the market    factor; and-   the range of filtered simulated market factor values for the market    factor structured to include an average value in the set of filtered    simulated market scenarios for the market factor.-   314. The apparatus of embodiment 301, further, comprising:-   each market factor interaction-interface mechanism in the set of    market factor interaction-interface mechanisms is structured to    include a slider interaction-interface mechanism to affect user    modification to a range of allowable values of a market factor    associated with the respective market factor interaction-interface    mechanism.-   315. The apparatus of embodiment 301, further, comprising:-   the instructions to update the set of customized market factors    based on the user modification are structured to comprise    instructions to add the modified market factor to the set of    customized market factors.-   316. The apparatus of embodiment 301, further, comprising:-   the instructions to update the set of customized market factors    based on the user modification are structured to comprise    instructions to remove the modified market factor from the set of    customized market factors.-   317. The apparatus of embodiment 301, further, comprising:-   the processor-executable instructions structured as:    -   generate, via at least one processor, a predefined scenario        datastructure that includes a simulation identifier associated        with the set of simulated market scenarios, identifiers of        customized market factors from the set of customized market        factors, and the ranges of allowable values for the set of        customized market factors.-   318. The apparatus of embodiment 301, further, comprising:-   the processor-executable instructions structured as:    -   generate, via at least one processor, a predefined scenario        datastructure that includes a simulation identifier associated        with the set of simulated market scenarios, and identifiers of        filtered simulated market scenarios from the set of filtered        simulated market scenarios.-   319. The apparatus of embodiment 301, further, comprising:-   the processor-executable instructions structured as:    -   generate, via at least one processor, a set of factor group        filter interaction-interface mechanisms, each factor group        filter interaction-interface mechanism in the set of factor        group filter interaction-interface mechanisms structured to be        associated with a subset of market factor interaction-interface        mechanisms from the set of market factor interaction-interface        mechanisms.-   320. The apparatus of embodiment 319, further, comprising:-   the processor-executable instructions structured as:    -   obtain, via at least one processor, a user selection of a factor        group filter interaction-interface mechanism in the set of        factor group filter interaction-interface mechanisms; and    -   generate, via at least one processor, a filtered set of market        factor interaction-interface mechanisms, each filtered market        factor interaction-interface mechanism in the set of filtered        market factor interaction-interface mechanisms structured to be        associated with the selected factor group filter        interaction-interface mechanism.-   321. A machine learning predefined scenario constructing    processor-readable, non-transient medium, comprising    processor-executable instructions structured as:    -   obtain, via at least one processor, a user selection of a set of        simulated market scenarios via a simulation selection        interaction-interface mechanism, the set of simulated market        scenarios generated using a set of deep learning neural        networks, each simulated market scenario in the set of simulated        market scenarios structured to comprise a set of simulated        market factor values corresponding to a set of market factors;    -   determine, via at least one processor, a range of unfiltered        simulated market factor values for each market factor from the        set of market factors, the range of unfiltered simulated market        factor values for a market factor structured to include a        minimum simulated market factor value and a maximum simulated        market factor value in the set of simulated market scenarios for        the respective market factor;    -   generate, via at least one processor, a set of market factor        interaction-interface mechanisms, each market factor        interaction-interface mechanism in the set of market factor        interaction-interface mechanisms structured to be associated        with a market factor from the set of market factors and        structured to display the range of unfiltered simulated market        factor values for the respective market factor;    -   obtain, via at least one processor, a user modification to a        range of allowable values of a market factor from the set of        market factors via the market factor interaction-interface        mechanism associated with the modified market factor;    -   update, via at least one processor, a set of customized market        factors from the set of market factors based on the user        modification;    -   determine, via at least one processor, a range of allowable        values for each customized market factor from the set of        customized market factors;    -   filter, via at least one processor, the set of simulated market        scenarios based on the determined ranges of allowable values for        the set of customized market factors to determine a set of        filtered simulated market scenarios having simulated market        factor values that fall within the range of allowable values for        each customized market factors from the set of customized market        factors;    -   determine, via at least one processor, a range of filtered        simulated market factor values for each market factor from the        set of market factors, the range of filtered simulated market        factor values for a market factor structured to include a        minimum simulated market factor value and a maximum simulated        market factor value in the set of filtered simulated market        scenarios for the respective market factor; and    -   generate, via at least one processor, an updated set of market        factor interaction-interface mechanisms, each updated market        factor interaction-interface mechanism in the set of updated        market factor interaction-interface mechanisms structured to be        associated with a market factor from the set of market factors        and structured to display the range of filtered simulated market        factor values for the respective market factor.-   322. The medium of embodiment 321, further, comprising:-   the instructions to generate the set of simulated market scenarios    using the set of deep learning neural networks are structured to    comprise instructions to:    -   determine, via at least one processor, a set of historical        market scenarios and a set of time period buckets;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a subset of        historical market scenarios, from the set of historical market        scenarios, associated with the respective time period bucket;    -   train, via at least one processor, for each time period bucket        from the set of time period buckets, a deep learning neural        network, from the set of deep learning neural networks, using        the subset of historical market scenarios associated with the        respective time period bucket;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a number of        simulated market scenarios to generate using the trained deep        learning neural network associated with the respective time        period bucket; and    -   generate, via at least one processor, for each time period        bucket from the set of time period buckets, the determined        number of simulated market scenarios for the respective time        period bucket, using the trained deep learning neural network        associated with the respective time period bucket.-   323. The medium of embodiment 322, further, comprising:-   the instructions to determine the set of historical market scenarios    are structured to comprise instructions to:    -   determine, via at least one processor, a historical data set, a        rolling window period length, and the set of market factors;    -   determine, via at least one processor, a set of rolling window        periods using the historical data set and the rolling window        period length; and    -   calculate, via at least one processor, for each market factor        from the set of market factors, for each rolling window period        from the set of rolling window periods, a change to the        respective market factor during the respective rolling window        period,        -   each historical market scenario from the set of historical            market scenarios structured to comprise calculated changes            to the set of market factors during a rolling window period.-   324. The medium of embodiment 323, further, comprising:-   the instructions to calculate a change to a market factor during a    rolling window period are structured to comprise instructions to:    -   determine, via at least one processor, the delta between values        of the market factor at a beginning time point and an ending        time point of the rolling window period.-   325. The medium of embodiment 324, further, comprising:-   the processor-executable instructions structured as:    -   determine, via at least one processor, that historical data for        the market factor during the rolling window period is        unavailable for a time point; and    -   impute, via at least one processor, the unavailable historical        data for the time point using a machine learning method.-   326. The medium of embodiment 323, further, comprising:-   the rolling window period length is structured to be equal to the    time period length.-   327. The medium of embodiment 322, further, comprising:-   the set of time period buckets is structured to have an equal fixed    length for each time period bucket.-   328. The medium of embodiment 322, further, comprising:-   the set of time period buckets is structured to have a variable    length for each time period bucket, the variable length for each    time period bucket determined by judging the overall goodness of fit    between the set of simulated market scenarios and the set of    historical market scenarios.-   329. The medium of embodiment 322, further, comprising:-   the instructions to train a deep learning neural network for a time    period bucket using the associated subset of historical market    scenarios are structured to comprise instructions to:    -   select, via at least one processor, a historical market scenario        from the associated subset of historical market scenarios; and    -   train, via at least one processor, the deep learning neural        network for the time period bucket on the selected historical        market scenario using a variational autoencoder.-   330. The medium of embodiment 329, further, comprising:-   the deep learning neural network for the time period bucket is    trained to generate a set of Gaussian mixture latent variables.-   331. The medium of embodiment 330, further, comprising:-   the instructions to generate simulated market scenarios for the time    period bucket, using the trained deep learning neural network    associated with the time period bucket, are structured to comprise    instructions to:    -   generate, via at least one processor, a set of random values for        the set of Gaussian mixture latent variables; and    -   generate a simulated market scenario, from the simulated market        scenarios for the time period bucket, from the generated set of        random values using a neural network decoder of the trained deep        learning neural network associated with the time period bucket.-   332. The medium of embodiment 321, further, comprising:-   the simulation selection interaction-interface mechanism is    structured to comprise a pricing date selection    interaction-interface mechanism and a simulation model selection    interaction-interface mechanism.-   333. The medium of embodiment 321, further, comprising:-   the range of unfiltered simulated market factor values for a market    factor structured to include an average simulated market factor    value in the set of simulated market scenarios for the market    factor; and-   the range of filtered simulated market factor values for the market    factor structured to include an average value in the set of filtered    simulated market scenarios for the market factor.-   334. The medium of embodiment 321, further, comprising:-   each market factor interaction-interface mechanism in the set of    market factor interaction-interface mechanisms is structured to    include a slider interaction-interface mechanism to affect user    modification to a range of allowable values of a market factor    associated with the respective market factor interaction-interface    mechanism.-   335. The medium of embodiment 321, further, comprising:-   the instructions to update the set of customized market factors    based on the user modification are structured to comprise    instructions to add the modified market factor to the set of    customized market factors.-   336. The medium of embodiment 321, further, comprising:-   the instructions to update the set of customized market factors    based on the user modification are structured to comprise    instructions to remove the modified market factor from the set of    customized market factors.-   337. The medium of embodiment 321, further, comprising:-   the processor-executable instructions structured as:    -   generate, via at least one processor, a predefined scenario        datastructure that includes a simulation identifier associated        with the set of simulated market scenarios, identifiers of        customized market factors from the set of customized market        factors, and the ranges of allowable values for the set of        customized market factors.-   338. The medium of embodiment 321, further, comprising:-   the processor-executable instructions structured as:    -   generate, via at least one processor, a predefined scenario        datastructure that includes a simulation identifier associated        with the set of simulated market scenarios, and identifiers of        filtered simulated market scenarios from the set of filtered        simulated market scenarios.-   339. The medium of embodiment 321, further, comprising:-   the processor-executable instructions structured as:    -   generate, via at least one processor, a set of factor group        filter interaction-interface mechanisms, each factor group        filter interaction-interface mechanism in the set of factor        group filter interaction-interface mechanisms structured to be        associated with a subset of market factor interaction-interface        mechanisms from the set of market factor interaction-interface        mechanisms.-   340. The medium of embodiment 339, further, comprising:-   the processor-executable instructions structured as:    -   obtain, via at least one processor, a user selection of a factor        group filter interaction-interface mechanism in the set of        factor group filter interaction-interface mechanisms; and    -   generate, via at least one processor, a filtered set of market        factor interaction-interface mechanisms, each filtered market        factor interaction-interface mechanism in the set of filtered        market factor interaction-interface mechanisms structured to be        associated with the selected factor group filter        interaction-interface mechanism.-   341. A machine learning predefined scenario constructing    processor-implemented system, comprising: means to process    processor-executable instructions;-   means to issue processor-issuable instructions from a    processor-executable component collection via the means to process    processor-executable instructions, the processor-issuable    instructions structured as:    -   obtain, via at least one processor, a user selection of a set of        simulated market scenarios via a simulation selection        interaction-interface mechanism, the set of simulated market        scenarios generated using a set of deep learning neural        networks, each simulated market scenario in the set of simulated        market scenarios structured to comprise a set of simulated        market factor values corresponding to a set of market factors;    -   determine, via at least one processor, a range of unfiltered        simulated market factor values for each market factor from the        set of market factors, the range of unfiltered simulated market        factor values for a market factor structured to include a        minimum simulated market factor value and a maximum simulated        market factor value in the set of simulated market scenarios for        the respective market factor;    -   generate, via at least one processor, a set of market factor        interaction-interface mechanisms, each market factor        interaction-interface mechanism in the set of market factor        interaction-interface mechanisms structured to be associated        with a market factor from the set of market factors and        structured to display the range of unfiltered simulated market        factor values for the respective market factor;    -   obtain, via at least one processor, a user modification to a        range of allowable values of a market factor from the set of        market factors via the market factor interaction-interface        mechanism associated with the modified market factor;    -   update, via at least one processor, a set of customized market        factors from the set of market factors based on the user        modification;    -   determine, via at least one processor, a range of allowable        values for each customized market factor from the set of        customized market factors;    -   filter, via at least one processor, the set of simulated market        scenarios based on the determined ranges of allowable values for        the set of customized market factors to determine a set of        filtered simulated market scenarios having simulated market        factor values that fall within the range of allowable values for        each customized market factors from the set of customized market        factors;    -   determine, via at least one processor, a range of filtered        simulated market factor values for each market factor from the        set of market factors, the range of filtered simulated market        factor values for a market factor structured to include a        minimum simulated market factor value and a maximum simulated        market factor value in the set of filtered simulated market        scenarios for the respective market factor; and    -   generate, via at least one processor, an updated set of market        factor interaction-interface mechanisms, each updated market        factor interaction-interface mechanism in the set of updated        market factor interaction-interface mechanisms structured to be        associated with a market factor from the set of market factors        and structured to display the range of filtered simulated market        factor values for the respective market factor.-   342. The system of embodiment 341, further, comprising:-   the instructions to generate the set of simulated market scenarios    using the set of deep learning neural networks are structured to    comprise instructions to:    -   determine, via at least one processor, a set of historical        market scenarios and a set of time period buckets;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a subset of        historical market scenarios, from the set of historical market        scenarios, associated with the respective time period bucket;    -   train, via at least one processor, for each time period bucket        from the set of time period buckets, a deep learning neural        network, from the set of deep learning neural networks, using        the subset of historical market scenarios associated with the        respective time period bucket;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a number of        simulated market scenarios to generate using the trained deep        learning neural network associated with the respective time        period bucket; and    -   generate, via at least one processor, for each time period        bucket from the set of time period buckets, the determined        number of simulated market scenarios for the respective time        period bucket, using the trained deep learning neural network        associated with the respective time period bucket.-   343. The system of embodiment 342, further, comprising:-   the instructions to determine the set of historical market scenarios    are structured to comprise instructions to:    -   determine, via at least one processor, a historical data set, a        rolling window period length, and the set of market factors;    -   determine, via at least one processor, a set of rolling window        periods using the historical data set and the rolling window        period length; and    -   calculate, via at least one processor, for each market factor        from the set of market factors, for each rolling window period        from the set of rolling window periods, a change to the        respective market factor during the respective rolling window        period,        -   each historical market scenario from the set of historical            market scenarios structured to comprise calculated changes            to the set of market factors during a rolling window period.-   344. The system of embodiment 343, further, comprising:-   the instructions to calculate a change to a market factor during a    rolling window period are structured to comprise instructions to:    -   determine, via at least one processor, the delta between values        of the market factor at a beginning time point and an ending        time point of the rolling window period.-   345. The system of embodiment 344, further, comprising:-   the processor-executable instructions structured as:    -   determine, via at least one processor, that historical data for        the market factor during the rolling window period is        unavailable for a time point; and    -   impute, via at least one processor, the unavailable historical        data for the time point using a machine learning method.-   346. The system of embodiment 343, further, comprising:-   the rolling window period length is structured to be equal to the    time period length.-   347. The system of embodiment 342, further, comprising:-   the set of time period buckets is structured to have an equal fixed    length for each time period bucket.-   348. The system of embodiment 342, further, comprising:-   the set of time period buckets is structured to have a variable    length for each time period bucket, the variable length for each    time period bucket determined by judging the overall goodness of fit    between the set of simulated market scenarios and the set of    historical market scenarios.-   349. The system of embodiment 342, further, comprising:-   the instructions to train a deep learning neural network for a time    period bucket using the associated subset of historical market    scenarios are structured to comprise instructions to:    -   select, via at least one processor, a historical market scenario        from the associated subset of historical market scenarios; and    -   train, via at least one processor, the deep learning neural        network for the time period bucket on the selected historical        market scenario using a variational autoencoder.-   350. The system of embodiment 349, further, comprising:-   the deep learning neural network for the time period bucket is    trained to generate a set of Gaussian mixture latent variables.-   351. The system of embodiment 350, further, comprising:-   the instructions to generate simulated market scenarios for the time    period bucket, using the trained deep learning neural network    associated with the time period bucket, are structured to comprise    instructions to:    -   generate, via at least one processor, a set of random values for        the set of Gaussian mixture latent variables; and    -   generate a simulated market scenario, from the simulated market        scenarios for the time period bucket, from the generated set of        random values using a neural network decoder of the trained deep        learning neural network associated with the time period bucket.-   352. The system of embodiment 341, further, comprising:-   the simulation selection interaction-interface mechanism is    structured to comprise a pricing date selection    interaction-interface mechanism and a simulation model selection    interaction-interface mechanism.-   353. The system of embodiment 341, further, comprising:-   the range of unfiltered simulated market factor values for a market    factor structured to include an average simulated market factor    value in the set of simulated market scenarios for the market    factor; and-   the range of filtered simulated market factor values for the market    factor structured to include an average value in the set of filtered    simulated market scenarios for the market factor.-   354. The system of embodiment 341, further, comprising:-   each market factor interaction-interface mechanism in the set of    market factor interaction-interface mechanisms is structured to    include a slider interaction-interface mechanism to affect user    modification to a range of allowable values of a market factor    associated with the respective market factor interaction-interface    mechanism.-   355. The system of embodiment 341, further, comprising:-   the instructions to update the set of customized market factors    based on the user modification are structured to comprise    instructions to add the modified market factor to the set of    customized market factors.-   356. The system of embodiment 341, further, comprising:-   the instructions to update the set of customized market factors    based on the user modification are structured to comprise    instructions to remove the modified market factor from the set of    customized market factors.-   357. The system of embodiment 341, further, comprising:-   the processor-executable instructions structured as:    -   generate, via at least one processor, a predefined scenario        datastructure that includes a simulation identifier associated        with the set of simulated market scenarios, identifiers of        customized market factors from the set of customized market        factors, and the ranges of allowable values for the set of        customized market factors.-   358. The system of embodiment 341, further, comprising:-   the processor-executable instructions structured as:    -   generate, via at least one processor, a predefined scenario        datastructure that includes a simulation identifier associated        with the set of simulated market scenarios, and identifiers of        filtered simulated market scenarios from the set of filtered        simulated market scenarios.-   359. The system of embodiment 341, further, comprising:-   the processor-executable instructions structured as:    -   generate, via at least one processor, a set of factor group        filter interaction-interface mechanisms, each factor group        filter interaction-interface mechanism in the set of factor        group filter interaction-interface mechanisms structured to be        associated with a subset of market factor interaction-interface        mechanisms from the set of market factor interaction-interface        mechanisms.-   360. The system of embodiment 359, further, comprising:-   the processor-executable instructions structured as:    -   obtain, via at least one processor, a user selection of a factor        group filter interaction-interface mechanism in the set of        factor group filter interaction-interface mechanisms; and    -   generate, via at least one processor, a filtered set of market        factor interaction-interface mechanisms, each filtered market        factor interaction-interface mechanism in the set of filtered        market factor interaction-interface mechanisms structured to be        associated with the selected factor group filter        interaction-interface mechanism.-   361. A machine learning predefined scenario constructing    processor-implemented process, comprising executing    processor-executable instructions to:    -   obtain, via at least one processor, a user selection of a set of        simulated market scenarios via a simulation selection        interaction-interface mechanism, the set of simulated market        scenarios generated using a set of deep learning neural        networks, each simulated market scenario in the set of simulated        market scenarios structured to comprise a set of simulated        market factor values corresponding to a set of market factors;    -   determine, via at least one processor, a range of unfiltered        simulated market factor values for each market factor from the        set of market factors, the range of unfiltered simulated market        factor values for a market factor structured to include a        minimum simulated market factor value and a maximum simulated        market factor value in the set of simulated market scenarios for        the respective market factor;    -   generate, via at least one processor, a set of market factor        interaction-interface mechanisms, each market factor        interaction-interface mechanism in the set of market factor        interaction-interface mechanisms structured to be associated        with a market factor from the set of market factors and        structured to display the range of unfiltered simulated market        factor values for the respective market factor;    -   obtain, via at least one processor, a user modification to a        range of allowable values of a market factor from the set of        market factors via the market factor interaction-interface        mechanism associated with the modified market factor;    -   update, via at least one processor, a set of customized market        factors from the set of market factors based on the user        modification;    -   determine, via at least one processor, a range of allowable        values for each customized market factor from the set of        customized market factors;    -   filter, via at least one processor, the set of simulated market        scenarios based on the determined ranges of allowable values for        the set of customized market factors to determine a set of        filtered simulated market scenarios having simulated market        factor values that fall within the range of allowable values for        each customized market factors from the set of customized market        factors;    -   determine, via at least one processor, a range of filtered        simulated market factor values for each market factor from the        set of market factors, the range of filtered simulated market        factor values for a market factor structured to include a        minimum simulated market factor value and a maximum simulated        market factor value in the set of filtered simulated market        scenarios for the respective market factor; and    -   generate, via at least one processor, an updated set of market        factor interaction-interface mechanisms, each updated market        factor interaction-interface mechanism in the set of updated        market factor interaction-interface mechanisms structured to be        associated with a market factor from the set of market factors        and structured to display the range of filtered simulated market        factor values for the respective market factor.-   362. The process of embodiment 361, further, comprising:-   the instructions to generate the set of simulated market scenarios    using the set of deep learning neural networks are structured to    comprise instructions to:    -   determine, via at least one processor, a set of historical        market scenarios and a set of time period buckets;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a subset of        historical market scenarios, from the set of historical market        scenarios, associated with the respective time period bucket;    -   train, via at least one processor, for each time period bucket        from the set of time period buckets, a deep learning neural        network, from the set of deep learning neural networks, using        the subset of historical market scenarios associated with the        respective time period bucket;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a number of        simulated market scenarios to generate using the trained deep        learning neural network associated with the respective time        period bucket; and    -   generate, via at least one processor, for each time period        bucket from the set of time period buckets, the determined        number of simulated market scenarios for the respective time        period bucket, using the trained deep learning neural network        associated with the respective time period bucket.-   363. The process of embodiment 362, further, comprising:-   the instructions to determine the set of historical market scenarios    are structured to comprise instructions to:    -   determine, via at least one processor, a historical data set, a        rolling window period length, and the set of market factors;    -   determine, via at least one processor, a set of rolling window        periods using the historical data set and the rolling window        period length; and    -   calculate, via at least one processor, for each market factor        from the set of market factors, for each rolling window period        from the set of rolling window periods, a change to the        respective market factor during the respective rolling window        period,        -   each historical market scenario from the set of historical            market scenarios structured to comprise calculated changes            to the set of market factors during a rolling window period.-   364. The process of embodiment 363, further, comprising:-   the instructions to calculate a change to a market factor during a    rolling window period are structured to comprise instructions to:    -   determine, via at least one processor, the delta between values        of the market factor at a beginning time point and an ending        time point of the rolling window period.-   365. The process of embodiment 364, further, comprising:-   the processor-executable instructions structured as:    -   determine, via at least one processor, that historical data for        the market factor during the rolling window period is        unavailable for a time point; and    -   impute, via at least one processor, the unavailable historical        data for the time point using a machine learning method.-   366. The process of embodiment 363, further, comprising:-   the rolling window period length is structured to be equal to the    time period length.-   367. The process of embodiment 362, further, comprising:-   the set of time period buckets is structured to have an equal fixed    length for each time period bucket.-   368. The process of embodiment 362, further, comprising:-   the set of time period buckets is structured to have a variable    length for each time period bucket, the variable length for each    time period bucket determined by judging the overall goodness of fit    between the set of simulated market scenarios and the set of    historical market scenarios.-   369. The process of embodiment 362, further, comprising:-   the instructions to train a deep learning neural network for a time    period bucket using the associated subset of historical market    scenarios are structured to comprise instructions to:    -   select, via at least one processor, a historical market scenario        from the associated subset of historical market scenarios; and    -   train, via at least one processor, the deep learning neural        network for the time period bucket on the selected historical        market scenario using a variational autoencoder.-   370. The process of embodiment 369, further, comprising:-   the deep learning neural network for the time period bucket is    trained to generate a set of Gaussian mixture latent variables.-   371. The process of embodiment 370, further, comprising:-   the instructions to generate simulated market scenarios for the time    period bucket, using the trained deep learning neural network    associated with the time period bucket, are structured to comprise    instructions to:    -   generate, via at least one processor, a set of random values for        the set of Gaussian mixture latent variables; and    -   generate a simulated market scenario, from the simulated market        scenarios for the time period bucket, from the generated set of        random values using a neural network decoder of the trained deep        learning neural network associated with the time period bucket.-   372. The process of embodiment 361, further, comprising:-   the simulation selection interaction-interface mechanism is    structured to comprise a pricing date selection    interaction-interface mechanism and a simulation model selection    interaction-interface mechanism.-   373. The process of embodiment 361, further, comprising:-   the range of unfiltered simulated market factor values for a market    factor structured to include an average simulated market factor    value in the set of simulated market scenarios for the market    factor; and-   the range of filtered simulated market factor values for the market    factor structured to include an average value in the set of filtered    simulated market scenarios for the market factor.-   374. The process of embodiment 361, further, comprising:-   each market factor interaction-interface mechanism in the set of    market factor interaction-interface mechanisms is structured to    include a slider interaction-interface mechanism to affect user    modification to a range of allowable values of a market factor    associated with the respective market factor interaction-interface    mechanism.-   375. The process of embodiment 361, further, comprising:-   the instructions to update the set of customized market factors    based on the user modification are structured to comprise    instructions to add the modified market factor to the set of    customized market factors.-   376. The process of embodiment 361, further, comprising:-   the instructions to update the set of customized market factors    based on the user modification are structured to comprise    instructions to remove the modified market factor from the set of    customized market factors.-   377. The process of embodiment 361, further, comprising:-   the processor-executable instructions structured as:    -   generate, via at least one processor, a predefined scenario        datastructure that includes a simulation identifier associated        with the set of simulated market scenarios, identifiers of        customized market factors from the set of customized market        factors, and the ranges of allowable values for the set of        customized market factors.-   378. The process of embodiment 361, further, comprising:-   the processor-executable instructions structured as:    -   generate, via at least one processor, a predefined scenario        datastructure that includes a simulation identifier associated        with the set of simulated market scenarios, and identifiers of        filtered simulated market scenarios from the set of filtered        simulated market scenarios.-   379. The process of embodiment 361, further, comprising:-   the processor-executable instructions structured as:    -   generate, via at least one processor, a set of factor group        filter interaction-interface mechanisms, each factor group        filter interaction-interface mechanism in the set of factor        group filter interaction-interface mechanisms structured to be        associated with a subset of market factor interaction-interface        mechanisms from the set of market factor interaction-interface        mechanisms.-   380. The process of embodiment 379, further, comprising:-   the processor-executable instructions structured as:    -   obtain, via at least one processor, a user selection of a factor        group filter interaction-interface mechanism in the set of        factor group filter interaction-interface mechanisms; and    -   generate, via at least one processor, a filtered set of market        factor interaction-interface mechanisms, each filtered market        factor interaction-interface mechanism in the set of filtered        market factor interaction-interface mechanisms structured to be        associated with the selected factor group filter        interaction-interface mechanism.-   401. A machine learning predefined scenario constructing apparatus,    comprising:-   a memory;-   a component collection in the memory;-   a processor disposed in communication with the memory and configured    to issue a plurality of processor-executable instructions from the    component collection, the processor-executable instructions    structured as:    -   obtain, via at least one processor, a user selection of a set of        simulated market scenarios via a simulation selection        interaction-interface mechanism, the set of simulated market        scenarios generated using a set of multi-variate mixture        datastructures, each simulated market scenario in the set of        simulated market scenarios structured to comprise a set of        simulated market factor values corresponding to a set of market        factors;    -   determine, via at least one processor, a range of unfiltered        simulated market factor values for each market factor from the        set of market factors, the range of unfiltered simulated market        factor values for a market factor structured to include a        minimum simulated market factor value and a maximum simulated        market factor value in the set of simulated market scenarios for        the respective market factor;    -   generate, via at least one processor, a set of market factor        interaction-interface mechanisms, each market factor        interaction-interface mechanism in the set of market factor        interaction-interface mechanisms structured to be associated        with a market factor from the set of market factors and        structured to display the range of unfiltered simulated market        factor values for the respective market factor;    -   obtain, via at least one processor, a user modification to a        range of allowable values of a market factor from the set of        market factors via the market factor interaction-interface        mechanism associated with the modified market factor;    -   update, via at least one processor, a set of customized market        factors from the set of market factors based on the user        modification;    -   determine, via at least one processor, a range of allowable        values for each customized market factor from the set of        customized market factors;    -   filter, via at least one processor, the set of simulated market        scenarios based on the determined ranges of allowable values for        the set of customized market factors to determine a set of        filtered simulated market scenarios having simulated market        factor values that fall within the range of allowable values for        each customized market factors from the set of customized market        factors;    -   determine, via at least one processor, a range of filtered        simulated market factor values for each market factor from the        set of market factors, the range of filtered simulated market        factor values for a market factor structured to include a        minimum simulated market factor value and a maximum simulated        market factor value in the set of filtered simulated market        scenarios for the respective market factor; and    -   generate, via at least one processor, an updated set of market        factor interaction-interface mechanisms, each updated market        factor interaction-interface mechanism in the set of updated        market factor interaction-interface mechanisms structured to be        associated with a market factor from the set of market factors        and structured to display the range of filtered simulated market        factor values for the respective market factor.-   402. The apparatus of embodiment 401, further, comprising:-   the instructions to generate the set of simulated market scenarios    using the set of multi-variate mixture datastructures are structured    to comprise instructions to    -   determine, via at least one processor, a set of historical        market scenarios and a set of time period buckets;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a subset of        historical market scenarios, from the set of historical market        scenarios, associated with the respective time period bucket;    -   train, via at least one processor, for each time period bucket        from the set of time period buckets, a multi-variate mixture        datastructure, from the set of multi-variate mixture        datastructures, using the subset of historical market scenarios        associated with the respective time period bucket;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a number of        simulated market scenarios to generate using the trained        multi-variate mixture datastructure associated with the        respective time period bucket; and    -   generate, via at least one processor, for each time period        bucket from the set of time period buckets, the determined        number of simulated market scenarios for the respective time        period bucket, using the trained multi-variate mixture        datastructures associated with the respective time period        bucket.-   403. The apparatus of embodiment 402, further, comprising:-   the instructions to determine the set of historical market scenarios    are structured to comprise instructions to:    -   determine, via at least one processor, a historical data set and        the set of market factors;    -   determine, via at least one processor, a set of rolling window        periods for the historical data set; and    -   calculate, via at least one processor, for each market factor        from the set of market factors, for each rolling window period        from the set of rolling window periods, a change to the        respective market factor during the respective rolling window        period,        -   each historical market scenario from the set of historical            market scenarios structured to comprise calculated changes            to the set of market factors during a rolling window period.-   404. The apparatus of embodiment 403, further, comprising:-   the instructions to calculate a change to a market factor during a    rolling window period are structured to comprise instructions to:    -   determine, via at least one processor, the delta between values        of the market factor at two time point of the rolling window        period.-   405. The apparatus of embodiment 404, further, comprising:-   the processor-executable instructions structured as:    -   determine, via at least one processor, that historical data for        the market factor during the rolling window period is        unavailable for a time point; and    -   impute, via at least one processor, the unavailable historical        data for the time point using a k-Nearest Neighbors method.-   406. The apparatus of embodiment 403, further, comprising:-   the length of a rolling window period is structured to be equal to    the time period length.-   407. The apparatus of embodiment 402, further, comprising:-   the set of time period buckets is structured to have a fixed length    for each time period bucket.-   408. The apparatus of embodiment 402, further, comprising:-   the set of time period buckets is structured to have variable    lengths, the variable length for each time period bucket reflective    of changes in volatilities and correlations of the set of historical    market scenarios.-   409. The apparatus of embodiment 403, further, comprising:-   the instructions to train a multi-variate mixture datastructure for    a time period bucket using the associated subset of historical    market scenarios are structured to comprise instructions to:    -   determine, via at least one processor, for each market factor        from the set of market factors, a distribution to use for the        respective market factor for the time period bucket;    -   fit, via at least one processor, for each market factor from the        set of market factors, the distribution to use for the        respective market factor for the time period bucket using the        associated subset of historical market scenarios;    -   determine, via at least one processor, a copula for the set of        market factors for the time period bucket; and    -   train, via at least one processor, the multi-variate mixture        datastructure for the time period bucket using the fitted        distributions and the copula for the set of market factors.-   410. The apparatus of embodiment 409, further, comprising:-   the instructions to fit the distribution to use for a market factor    for the time period bucket using the associated subset of historical    market scenarios are structured to comprise instructions to    calculate the mean of the market factor's values in the associated    subset of historical market scenarios.-   411. The apparatus of embodiment 402, further, comprising:-   the instructions to generate simulated market scenarios for a time    period bucket, using the trained multi-variate mixture datastructure    associated with the time period bucket, are structured to comprise    instructions to:    -   generate a simulated market scenario, from the simulated market        scenarios for the time period bucket, by sampling the trained        multi-variate mixture datastructure associated with the time        period bucket.-   412. The apparatus of embodiment 401, further, comprising:-   the simulation selection interaction-interface mechanism is    structured to comprise a pricing date selection    interaction-interface mechanism and a simulation model selection    interaction-interface mechanism.-   413. The apparatus of embodiment 401, further, comprising:-   the range of unfiltered simulated market factor values for a market    factor structured to include an average simulated market factor    value in the set of simulated market scenarios for the market    factor; and-   the range of filtered simulated market factor values for the market    factor structured to include an average value in the set of filtered    simulated market scenarios for the market factor.-   414. The apparatus of embodiment 401, further, comprising:-   each market factor interaction-interface mechanism in the set of    market factor interaction-interface mechanisms is structured to    include a slider interaction-interface mechanism to affect user    modification to a range of allowable values of a market factor    associated with the respective market factor interaction-interface    mechanism.-   415. The apparatus of embodiment 401, further, comprising:-   the instructions to update the set of customized market factors    based on the user modification are structured to comprise    instructions to add the modified market factor to the set of    customized market factors.-   416. The apparatus of embodiment 401, further, comprising:-   the instructions to update the set of customized market factors    based on the user modification are structured to comprise    instructions to remove the modified market factor from the set of    customized market factors.-   417. The apparatus of embodiment 401, further, comprising:-   the processor-executable instructions structured as:    -   generate, via at least one processor, a predefined scenario        datastructure that includes a simulation identifier associated        with the set of simulated market scenarios, identifiers of        customized market factors from the set of customized market        factors, and the ranges of allowable values for the set of        customized market factors.-   418. The apparatus of embodiment 401, further, comprising:-   the processor-executable instructions structured as:    -   generate, via at least one processor, a predefined scenario        datastructure that includes a simulation identifier associated        with the set of simulated market scenarios, and identifiers of        filtered simulated market scenarios from the set of filtered        simulated market scenarios.-   419. The apparatus of embodiment 401, further, comprising:-   the processor-executable instructions structured as:    -   generate, via at least one processor, a set of factor group        filter interaction-interface mechanisms, each factor group        filter interaction-interface mechanism in the set of factor        group filter interaction-interface mechanisms structured to be        associated with a subset of market factor interaction-interface        mechanisms from the set of market factor interaction-interface        mechanisms.-   420. The apparatus of embodiment 419, further, comprising:-   the processor-executable instructions structured as:    -   obtain, via at least one processor, a user selection of a factor        group filter interaction-interface mechanism in the set of        factor group filter interaction-interface mechanisms; and    -   generate, via at least one processor, a filtered set of market        factor interaction-interface mechanisms, each filtered market        factor interaction-interface mechanism in the set of filtered        market factor interaction-interface mechanisms structured to be        associated with the selected factor group filter        interaction-interface mechanism.-   421. A machine learning predefined scenario constructing    processor-readable, non-transient medium, comprising    processor-executable instructions structured as:    -   obtain, via at least one processor, a user selection of a set of        simulated market scenarios via a simulation selection        interaction-interface mechanism, the set of simulated market        scenarios generated using a set of multi-variate mixture        datastructures, each simulated market scenario in the set of        simulated market scenarios structured to comprise a set of        simulated market factor values corresponding to a set of market        factors;    -   determine, via at least one processor, a range of unfiltered        simulated market factor values for each market factor from the        set of market factors, the range of unfiltered simulated market        factor values for a market factor structured to include a        minimum simulated market factor value and a maximum simulated        market factor value in the set of simulated market scenarios for        the respective market factor;    -   generate, via at least one processor, a set of market factor        interaction-interface mechanisms, each market factor        interaction-interface mechanism in the set of market factor        interaction-interface mechanisms structured to be associated        with a market factor from the set of market factors and        structured to display the range of unfiltered simulated market        factor values for the respective market factor;    -   obtain, via at least one processor, a user modification to a        range of allowable values of a market factor from the set of        market factors via the market factor interaction-interface        mechanism associated with the modified market factor;    -   update, via at least one processor, a set of customized market        factors from the set of market factors based on the user        modification;    -   determine, via at least one processor, a range of allowable        values for each customized market factor from the set of        customized market factors;    -   filter, via at least one processor, the set of simulated market        scenarios based on the determined ranges of allowable values for        the set of customized market factors to determine a set of        filtered simulated market scenarios having simulated market        factor values that fall within the range of allowable values for        each customized market factors from the set of customized market        factors;    -   determine, via at least one processor, a range of filtered        simulated market factor values for each market factor from the        set of market factors, the range of filtered simulated market        factor values for a market factor structured to include a        minimum simulated market factor value and a maximum simulated        market factor value in the set of filtered simulated market        scenarios for the respective market factor; and    -   generate, via at least one processor, an updated set of market        factor interaction-interface mechanisms, each updated market        factor interaction-interface mechanism in the set of updated        market factor interaction-interface mechanisms structured to be        associated with a market factor from the set of market factors        and structured to display the range of filtered simulated market        factor values for the respective market factor.-   422. The medium of embodiment 421, further, comprising:-   the instructions to generate the set of simulated market scenarios    using the set of multi-variate mixture datastructures are structured    to comprise instructions to    -   determine, via at least one processor, a set of historical        market scenarios and a set of time period buckets;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a subset of        historical market scenarios, from the set of historical market        scenarios, associated with the respective time period bucket;    -   train, via at least one processor, for each time period bucket        from the set of time period buckets, a multi-variate mixture        datastructure, from the set of multi-variate mixture        datastructures, using the subset of historical market scenarios        associated with the respective time period bucket;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a number of        simulated market scenarios to generate using the trained        multi-variate mixture datastructure associated with the        respective time period bucket; and    -   generate, via at least one processor, for each time period        bucket from the set of time period buckets, the determined        number of simulated market scenarios for the respective time        period bucket, using the trained multi-variate mixture        datastructures associated with the respective time period        bucket.-   423. The medium of embodiment 422, further, comprising:-   the instructions to determine the set of historical market scenarios    are structured to comprise instructions to:    -   determine, via at least one processor, a historical data set and        the set of market factors;    -   determine, via at least one processor, a set of rolling window        periods for the historical data set; and    -   calculate, via at least one processor, for each market factor        from the set of market factors, for each rolling window period        from the set of rolling window periods, a change to the        respective market factor during the respective rolling window        period,    -   each historical market scenario from the set of historical        market scenarios structured to comprise calculated changes to        the set of market factors during a rolling window period.-   424. The medium of embodiment 423, further, comprising:-   the instructions to calculate a change to a market factor during a    rolling window period are structured to comprise instructions to:    -   determine, via at least one processor, the delta between values        of the market factor at two time point of the rolling window        period.-   425. The medium of embodiment 424, further, comprising:-   the processor-executable instructions structured as:    -   determine, via at least one processor, that historical data for        the market factor during the rolling window period is        unavailable for a time point; and    -   impute, via at least one processor, the unavailable historical        data for the time point using a k-Nearest Neighbors method.-   426. The medium of embodiment 423, further, comprising:-   the length of a rolling window period is structured to be equal to    the time period length.-   427. The medium of embodiment 422, further, comprising:-   the set of time period buckets is structured to have a fixed length    for each time period bucket.-   428. The medium of embodiment 422, further, comprising:-   the set of time period buckets is structured to have variable    lengths, the variable length for each time period bucket reflective    of changes in volatilities and correlations of the set of historical    market scenarios.-   429. The medium of embodiment 423, further, comprising:-   the instructions to train a multi-variate mixture datastructure for    a time period bucket using the associated subset of historical    market scenarios are structured to comprise instructions to:    -   determine, via at least one processor, for each market factor        from the set of market factors, a distribution to use for the        respective market factor for the time period bucket;    -   fit, via at least one processor, for each market factor from the        set of market factors, the distribution to use for the        respective market factor for the time period bucket using the        associated subset of historical market scenarios;    -   determine, via at least one processor, a copula for the set of        market factors for the time period bucket; and    -   train, via at least one processor, the multi-variate mixture        datastructure for the time period bucket using the fitted        distributions and the copula for the set of market factors.-   430. The medium of embodiment 429, further, comprising:-   the instructions to fit the distribution to use for a market factor    for the time period bucket using the associated subset of historical    market scenarios are structured to comprise instructions to    calculate the mean of the market factor's values in the associated    subset of historical market scenarios.-   431. The medium of embodiment 422, further, comprising:-   the instructions to generate simulated market scenarios for a time    period bucket, using the trained multi-variate mixture datastructure    associated with the time period bucket, are structured to comprise    instructions to:    -   generate a simulated market scenario, from the simulated market        scenarios for the time period bucket, by sampling the trained        multi-variate mixture datastructure associated with the time        period bucket.-   432. The medium of embodiment 421, further, comprising:-   the simulation selection interaction-interface mechanism is    structured to comprise a pricing date selection    interaction-interface mechanism and a simulation model selection    interaction-interface mechanism.-   433. The medium of embodiment 421, further, comprising:-   the range of unfiltered simulated market factor values for a market    factor structured to include an average simulated market factor    value in the set of simulated market scenarios for the market    factor; and-   the range of filtered simulated market factor values for the market    factor structured to include an average value in the set of filtered    simulated market scenarios for the market factor.-   434. The medium of embodiment 421, further, comprising:-   each market factor interaction-interface mechanism in the set of    market factor interaction-interface mechanisms is structured to    include a slider interaction-interface mechanism to affect user    modification to a range of allowable values of a market factor    associated with the respective market factor interaction-interface    mechanism.-   435. The medium of embodiment 421, further, comprising:-   the instructions to update the set of customized market factors    based on the user modification are structured to comprise    instructions to add the modified market factor to the set of    customized market factors.-   436. The medium of embodiment 421, further, comprising:-   the instructions to update the set of customized market factors    based on the user modification are structured to comprise    instructions to remove the modified market factor from the set of    customized market factors.-   437. The medium of embodiment 421, further, comprising:-   the processor-executable instructions structured as:    -   generate, via at least one processor, a predefined scenario        datastructure that includes a simulation identifier associated        with the set of simulated market scenarios, identifiers of        customized market factors from the set of customized market        factors, and the ranges of allowable values for the set of        customized market factors.-   438. The medium of embodiment 421, further, comprising:-   the processor-executable instructions structured as:    -   generate, via at least one processor, a predefined scenario        datastructure that includes a simulation identifier associated        with the set of simulated market scenarios, and identifiers of        filtered simulated market scenarios from the set of filtered        simulated market scenarios.-   439. The medium of embodiment 421, further, comprising:-   the processor-executable instructions structured as:    -   generate, via at least one processor, a set of factor group        filter interaction-interface mechanisms, each factor group        filter interaction-interface mechanism in the set of factor        group filter interaction-interface mechanisms structured to be        associated with a subset of market factor interaction-interface        mechanisms from the set of market factor interaction-interface        mechanisms.-   440. The medium of embodiment 439, further, comprising:-   the processor-executable instructions structured as:    -   obtain, via at least one processor, a user selection of a factor        group filter interaction-interface mechanism in the set of        factor group filter interaction-interface mechanisms; and    -   generate, via at least one processor, a filtered set of market        factor interaction-interface mechanisms, each filtered market        factor interaction-interface mechanism in the set of filtered        market factor interaction-interface mechanisms structured to be        associated with the selected factor group filter        interaction-interface mechanism.-   441. A machine learning predefined scenario constructing    processor-implemented system, comprising: means to process    processor-executable instructions;-   means to issue processor-issuable instructions from a    processor-executable component collection via the means to process    processor-executable instructions, the processor-issuable    instructions structured as:    -   obtain, via at least one processor, a user selection of a set of        simulated market scenarios via a simulation selection        interaction-interface mechanism, the set of simulated market        scenarios generated using a set of multi-variate mixture        datastructures, each simulated market scenario in the set of        simulated market scenarios structured to comprise a set of        simulated market factor values corresponding to a set of market        factors;    -   determine, via at least one processor, a range of unfiltered        simulated market factor values for each market factor from the        set of market factors, the range of unfiltered simulated market        factor values for a market factor structured to include a        minimum simulated market factor value and a maximum simulated        market factor value in the set of simulated market scenarios for        the respective market factor;    -   generate, via at least one processor, a set of market factor        interaction-interface mechanisms, each market factor        interaction-interface mechanism in the set of market factor        interaction-interface mechanisms structured to be associated        with a market factor from the set of market factors and        structured to display the range of unfiltered simulated market        factor values for the respective market factor;    -   obtain, via at least one processor, a user modification to a        range of allowable values of a market factor from the set of        market factors via the market factor interaction-interface        mechanism associated with the modified market factor;    -   update, via at least one processor, a set of customized market        factors from the set of market factors based on the user        modification;    -   determine, via at least one processor, a range of allowable        values for each customized market factor from the set of        customized market factors;    -   filter, via at least one processor, the set of simulated market        scenarios based on the determined ranges of allowable values for        the set of customized market factors to determine a set of        filtered simulated market scenarios having simulated market        factor values that fall within the range of allowable values for        each customized market factors from the set of customized market        factors;    -   determine, via at least one processor, a range of filtered        simulated market factor values for each market factor from the        set of market factors, the range of filtered simulated market        factor values for a market factor structured to include a        minimum simulated market factor value and a maximum simulated        market factor value in the set of filtered simulated market        scenarios for the respective market factor; and    -   generate, via at least one processor, an updated set of market        factor interaction-interface mechanisms, each updated market        factor interaction-interface mechanism in the set of updated        market factor interaction-interface mechanisms structured to be        associated with a market factor from the set of market factors        and structured to display the range of filtered simulated market        factor values for the respective market factor.-   442. The system of embodiment 441, further, comprising:-   the instructions to generate the set of simulated market scenarios    using the set of multi-variate mixture datastructures are structured    to comprise instructions to    -   determine, via at least one processor, a set of historical        market scenarios and a set of time period buckets;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a subset of        historical market scenarios, from the set of historical market        scenarios, associated with the respective time period bucket;    -   train, via at least one processor, for each time period bucket        from the set of time period buckets, a multi-variate mixture        datastructure, from the set of multi-variate mixture        datastructures, using the subset of historical market scenarios        associated with the respective time period bucket;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a number of        simulated market scenarios to generate using the trained        multi-variate mixture datastructure associated with the        respective time period bucket; and    -   generate, via at least one processor, for each time period        bucket from the set of time period buckets, the determined        number of simulated market scenarios for the respective time        period bucket, using the trained multi-variate mixture        datastructures associated with the respective time period        bucket.-   443. The system of embodiment 442, further, comprising:-   the instructions to determine the set of historical market scenarios    are structured to comprise instructions to:    -   determine, via at least one processor, a historical data set and        the set of market factors;    -   determine, via at least one processor, a set of rolling window        periods for the historical data set; and    -   calculate, via at least one processor, for each market factor        from the set of market factors, for each rolling window period        from the set of rolling window periods, a change to the        respective market factor during the respective rolling window        period,        -   each historical market scenario from the set of historical            market scenarios structured to comprise calculated changes            to the set of market factors during a rolling window period.-   444. The system of embodiment 443, further, comprising:-   the instructions to calculate a change to a market factor during a    rolling window period are structured to comprise instructions to:    -   determine, via at least one processor, the delta between values        of the market factor at two time point of the rolling window        period.-   445. The system of embodiment 444, further, comprising:-   the processor-executable instructions structured as:    -   determine, via at least one processor, that historical data for        the market factor during the rolling window period is        unavailable for a time point; and    -   impute, via at least one processor, the unavailable historical        data for the time point using a k-Nearest Neighbors method.-   446. The system of embodiment 443, further, comprising:-   the length of a rolling window period is structured to be equal to    the time period length.-   447. The system of embodiment 442, further, comprising:-   the set of time period buckets is structured to have a fixed length    for each time period bucket.-   448. The system of embodiment 442, further, comprising:-   the set of time period buckets is structured to have variable    lengths, the variable length for each time period bucket reflective    of changes in volatilities and correlations of the set of historical    market scenarios.-   449. The system of embodiment 443, further, comprising:-   the instructions to train a multi-variate mixture datastructure for    a time period bucket using the associated subset of historical    market scenarios are structured to comprise instructions to:    -   determine, via at least one processor, for each market factor        from the set of market factors, a distribution to use for the        respective market factor for the time period bucket;    -   fit, via at least one processor, for each market factor from the        set of market factors, the distribution to use for the        respective market factor for the time period bucket using the        associated subset of historical market scenarios;    -   determine, via at least one processor, a copula for the set of        market factors for the time period bucket; and    -   train, via at least one processor, the multi-variate mixture        datastructure for the time period bucket using the fitted        distributions and the copula for the set of market factors.-   450. The system of embodiment 449, further, comprising:-   the instructions to fit the distribution to use for a market factor    for the time period bucket using the associated subset of historical    market scenarios are structured to comprise instructions to    calculate the mean of the market factor's values in the associated    subset of historical market scenarios.-   451. The system of embodiment 442, further, comprising:-   the instructions to generate simulated market scenarios for a time    period bucket, using the trained multi-variate mixture datastructure    associated with the time period bucket, are structured to comprise    instructions to:    -   generate a simulated market scenario, from the simulated market        scenarios for the time period bucket, by sampling the trained        multi-variate mixture datastructure associated with the time        period bucket.-   452. The system of embodiment 441, further, comprising:-   the simulation selection interaction-interface mechanism is    structured to comprise a pricing date selection    interaction-interface mechanism and a simulation model selection    interaction-interface mechanism.-   453. The system of embodiment 441, further, comprising:-   the range of unfiltered simulated market factor values for a market    factor structured to include an average simulated market factor    value in the set of simulated market scenarios for the market    factor; and-   the range of filtered simulated market factor values for the market    factor structured to include an average value in the set of filtered    simulated market scenarios for the market factor.-   454. The system of embodiment 441, further, comprising:-   each market factor interaction-interface mechanism in the set of    market factor interaction-interface mechanisms is structured to    include a slider interaction-interface mechanism to affect user    modification to a range of allowable values of a market factor    associated with the respective market factor interaction-interface    mechanism.-   455. The system of embodiment 441, further, comprising:-   the instructions to update the set of customized market factors    based on the user modification are structured to comprise    instructions to add the modified market factor to the set of    customized market factors.-   456. The system of embodiment 441, further, comprising:-   the instructions to update the set of customized market factors    based on the user modification are structured to comprise    instructions to remove the modified market factor from the set of    customized market factors.-   457. The system of embodiment 441, further, comprising:-   the processor-executable instructions structured as:    -   generate, via at least one processor, a predefined scenario        datastructure that includes a simulation identifier associated        with the set of simulated market scenarios, identifiers of        customized market factors from the set of customized market        factors, and the ranges of allowable values for the set of        customized market factors.-   458. The system of embodiment 441, further, comprising:-   the processor-executable instructions structured as:    -   generate, via at least one processor, a predefined scenario        datastructure that includes a simulation identifier associated        with the set of simulated market scenarios, and identifiers of        filtered simulated market scenarios from the set of filtered        simulated market scenarios.-   459. The system of embodiment 441, further, comprising:-   the processor-executable instructions structured as:    -   generate, via at least one processor, a set of factor group        filter interaction-interface mechanisms, each factor group        filter interaction-interface mechanism in the set of factor        group filter interaction-interface mechanisms structured to be        associated with a subset of market factor interaction-interface        mechanisms from the set of market factor interaction-interface        mechanisms.-   460. The system of embodiment 459, further, comprising:-   the processor-executable instructions structured as:    -   obtain, via at least one processor, a user selection of a factor        group filter interaction-interface mechanism in the set of        factor group filter interaction-interface mechanisms; and    -   generate, via at least one processor, a filtered set of market        factor interaction-interface mechanisms, each filtered market        factor interaction-interface mechanism in the set of filtered        market factor interaction-interface mechanisms structured to be        associated with the selected factor group filter        interaction-interface mechanism.-   461. A machine learning predefined scenario constructing    processor-implemented process, comprising executing    processor-executable instructions to:    -   obtain, via at least one processor, a user selection of a set of        simulated market scenarios via a simulation selection        interaction-interface mechanism, the set of simulated market        scenarios generated using a set of multi-variate mixture        datastructures, each simulated market scenario in the set of        simulated market scenarios structured to comprise a set of        simulated market factor values corresponding to a set of market        factors;    -   determine, via at least one processor, a range of unfiltered        simulated market factor values for each market factor from the        set of market factors, the range of unfiltered simulated market        factor values for a market factor structured to include a        minimum simulated market factor value and a maximum simulated        market factor value in the set of simulated market scenarios for        the respective market factor;    -   generate, via at least one processor, a set of market factor        interaction-interface mechanisms, each market factor        interaction-interface mechanism in the set of market factor        interaction-interface mechanisms structured to be associated        with a market factor from the set of market factors and        structured to display the range of unfiltered simulated market        factor values for the respective market factor;    -   obtain, via at least one processor, a user modification to a        range of allowable values of a market factor from the set of        market factors via the market factor interaction-interface        mechanism associated with the modified market factor;    -   update, via at least one processor, a set of customized market        factors from the set of market factors based on the user        modification;    -   determine, via at least one processor, a range of allowable        values for each customized market factor from the set of        customized market factors;    -   filter, via at least one processor, the set of simulated market        scenarios based on the determined ranges of allowable values for        the set of customized market factors to determine a set of        filtered simulated market scenarios having simulated market        factor values that fall within the range of allowable values for        each customized market factors from the set of customized market        factors;    -   determine, via at least one processor, a range of filtered        simulated market factor values for each market factor from the        set of market factors, the range of filtered simulated market        factor values for a market factor structured to include a        minimum simulated market factor value and a maximum simulated        market factor value in the set of filtered simulated market        scenarios for the respective market factor; and    -   generate, via at least one processor, an updated set of market        factor interaction-interface mechanisms, each updated market        factor interaction-interface mechanism in the set of updated        market factor interaction-interface mechanisms structured to be        associated with a market factor from the set of market factors        and structured to display the range of filtered simulated market        factor values for the respective market factor.-   462. The process of embodiment 461, further, comprising:-   the instructions to generate the set of simulated market scenarios    using the set of multi-variate mixture datastructures are structured    to comprise instructions to    -   determine, via at least one processor, a set of historical        market scenarios and a set of time period buckets;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a subset of        historical market scenarios, from the set of historical market        scenarios, associated with the respective time period bucket;    -   train, via at least one processor, for each time period bucket        from the set of time period buckets, a multi-variate mixture        datastructure, from the set of multi-variate mixture        datastructures, using the subset of historical market scenarios        associated with the respective time period bucket;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a number of        simulated market scenarios to generate using the trained        multi-variate mixture datastructure associated with the        respective time period bucket; and    -   generate, via at least one processor, for each time period        bucket from the set of time period buckets, the determined        number of simulated market scenarios for the respective time        period bucket, using the trained multi-variate mixture        datastructures associated with the respective time period        bucket.-   463. The process of embodiment 462, further, comprising:-   the instructions to determine the set of historical market scenarios    are structured to comprise instructions to:    -   determine, via at least one processor, a historical data set and        the set of market factors;    -   determine, via at least one processor, a set of rolling window        periods for the historical data set; and    -   calculate, via at least one processor, for each market factor        from the set of market factors, for each rolling window period        from the set of rolling window periods, a change to the        respective market factor during the respective rolling window        period,        -   each historical market scenario from the set of historical            market scenarios structured to comprise calculated changes            to the set of market factors during a rolling window period.-   464. The process of embodiment 463, further, comprising:-   the instructions to calculate a change to a market factor during a    rolling window period are structured to comprise instructions to:    -   determine, via at least one processor, the delta between values        of the market factor at two time point of the rolling window        period.-   465. The process of embodiment 464, further, comprising:-   the processor-executable instructions structured as:    -   determine, via at least one processor, that historical data for        the market factor during the rolling window period is        unavailable for a time point; and    -   impute, via at least one processor, the unavailable historical        data for the time point using a k-Nearest Neighbors method.-   466. The process of embodiment 463, further, comprising:-   the length of a rolling window period is structured to be equal to    the time period length.-   467. The process of embodiment 462, further, comprising:-   the set of time period buckets is structured to have a fixed length    for each time period bucket.-   468. The process of embodiment 462, further, comprising:-   the set of time period buckets is structured to have variable    lengths, the variable length for each time period bucket reflective    of changes in volatilities and correlations of the set of historical    market scenarios.-   469. The process of embodiment 463, further, comprising:-   the instructions to train a multi-variate mixture datastructure for    a time period bucket using the associated subset of historical    market scenarios are structured to comprise instructions to:    -   determine, via at least one processor, for each market factor        from the set of market factors, a distribution to use for the        respective market factor for the time period bucket;    -   fit, via at least one processor, for each market factor from the        set of market factors, the distribution to use for the        respective market factor for the time period bucket using the        associated subset of historical market scenarios;    -   determine, via at least one processor, a copula for the set of        market factors for the time period bucket; and    -   train, via at least one processor, the multi-variate mixture        datastructure for the time period bucket using the fitted        distributions and the copula for the set of market factors.-   470. The process of embodiment 469, further, comprising:-   the instructions to fit the distribution to use for a market factor    for the time period bucket using the associated subset of historical    market scenarios are structured to comprise instructions to    calculate the mean of the market factor's values in the associated    subset of historical market scenarios.-   471. The process of embodiment 462, further, comprising:-   the instructions to generate simulated market scenarios for a time    period bucket, using the trained multi-variate mixture datastructure    associated with the time period bucket, are structured to comprise    instructions to:    -   generate a simulated market scenario, from the simulated market        scenarios for the time period bucket, by sampling the trained        multi-variate mixture datastructure associated with the time        period bucket.-   472. The process of embodiment 461, further, comprising:-   the simulation selection interaction-interface mechanism is    structured to comprise a pricing date selection    interaction-interface mechanism and a simulation model selection    interaction-interface mechanism.-   473. The process of embodiment 461, further, comprising:-   the range of unfiltered simulated market factor values for a market    factor structured to include an average simulated market factor    value in the set of simulated market scenarios for the market    factor; and-   the range of filtered simulated market factor values for the market    factor structured to include an average value in the set of filtered    simulated market scenarios for the market factor.-   474. The process of embodiment 461, further, comprising:-   each market factor interaction-interface mechanism in the set of    market factor interaction-interface mechanisms is structured to    include a slider interaction-interface mechanism to affect user    modification to a range of allowable values of a market factor    associated with the respective market factor interaction-interface    mechanism.-   475. The process of embodiment 461, further, comprising:-   the instructions to update the set of customized market factors    based on the user modification are structured to comprise    instructions to add the modified market factor to the set of    customized market factors.-   476. The process of embodiment 461, further, comprising:-   the instructions to update the set of customized market factors    based on the user modification are structured to comprise    instructions to remove the modified market factor from the set of    customized market factors.-   477. The process of embodiment 461, further, comprising:-   the processor-executable instructions structured as:    -   generate, via at least one processor, a predefined scenario        datastructure that includes a simulation identifier associated        with the set of simulated market scenarios, identifiers of        customized market factors from the set of customized market        factors, and the ranges of allowable values for the set of        customized market factors.-   478. The process of embodiment 461, further, comprising:-   the processor-executable instructions structured as:    -   generate, via at least one processor, a predefined scenario        datastructure that includes a simulation identifier associated        with the set of simulated market scenarios, and identifiers of        filtered simulated market scenarios from the set of filtered        simulated market scenarios.-   479. The process of embodiment 461, further, comprising:-   the processor-executable instructions structured as:    -   generate, via at least one processor, a set of factor group        filter interaction-interface mechanisms, each factor group        filter interaction-interface mechanism in the set of factor        group filter interaction-interface mechanisms structured to be        associated with a subset of market factor interaction-interface        mechanisms from the set of market factor interaction-interface        mechanisms.-   480. The process of embodiment 479, further, comprising:-   the processor-executable instructions structured as:    -   obtain, via at least one processor, a user selection of a factor        group filter interaction-interface mechanism in the set of        factor group filter interaction-interface mechanisms; and    -   generate, via at least one processor, a filtered set of market        factor interaction-interface mechanisms, each filtered market        factor interaction-interface mechanism in the set of filtered        market factor interaction-interface mechanisms structured to be        associated with the selected factor group filter        interaction-interface mechanism.

501. A machine learning portfolio return computation engine apparatus,comprising:

-   a memory;-   a component collection in the memory;-   a processor disposed in communication with the memory and configured    to issue a plurality of processor-executable instructions from the    component collection, the processor-executable instructions    structured as:    -   obtain, via at least one processor, a portfolio return        computation request datastructure, the portfolio return        computation request datastructure structured to specify a set of        simulated market scenarios and a set of filters, the set of        simulated market scenarios generated using a set of deep        learning neural networks, each simulated market scenario in the        set of simulated market scenarios structured to comprise a set        of simulated market factor values corresponding to a set of        market factors;    -   determine, via at least one processor, a set of constituent        portfolio securities of a portfolio, each constituent portfolio        security in the set of constituent portfolio securities        associated with a portfolio security weight of the respective        constituent portfolio security in the portfolio;    -   filter, via at least one processor, the set of simulated market        scenarios based on the set of filters to determine a set of        filtered simulated market scenarios having simulated market        factor values that fall within the range of allowable values for        each filter in the set of filters;    -   retrieve, via at least one processor, a set of expected returns        for the set of constituent portfolio securities of the portfolio        for the set of filtered simulated market scenarios;    -   calculate, via at least one processor, for each constituent        portfolio security in the set of constituent portfolio        securities, an expected constituent portfolio security return        for the set of filtered simulated market scenarios as an average        of expected returns in the set of expected returns of the        respective constituent portfolio security; and    -   calculate, via at least one processor, an expected portfolio        return for the set of filtered simulated market scenarios as a        weighted average of the calculated expected constituent        portfolio security returns for the set of filtered simulated        market scenarios, an expected constituent portfolio security        return weighted in accordance with the portfolio security weight        of the associated portfolio security.-   502. The apparatus of embodiment 501, further, comprising:-   the instructions to generate the set of simulated market scenarios    using the set of deep learning neural networks are structured to    comprise instructions to:    -   determine, via at least one processor, a set of historical        market scenarios and a set of time period buckets;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a subset of        historical market scenarios, from the set of historical market        scenarios, associated with the respective time period bucket;    -   train, via at least one processor, for each time period bucket        from the set of time period buckets, a deep learning neural        network, from the set of deep learning neural networks, using        the subset of historical market scenarios associated with the        respective time period bucket;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a number of        simulated market scenarios to generate using the trained deep        learning neural network associated with the respective time        period bucket; and    -   generate, via at least one processor, for each time period        bucket from the set of time period buckets, the determined        number of simulated market scenarios for the respective time        period bucket, using the trained deep learning neural network        associated with the respective time period bucket.-   503. The apparatus of embodiment 502, further, comprising:-   the instructions to determine the set of historical market scenarios    are structured to comprise instructions to:    -   determine, via at least one processor, a historical data set, a        rolling window period length, and the set of market factors;    -   determine, via at least one processor, a set of rolling window        periods using the historical data set and the rolling window        period length; and    -   calculate, via at least one processor, for each market factor        from the set of market factors, for each rolling window period        from the set of rolling window periods, a change to the        respective market factor during the respective rolling window        period,    -   each historical market scenario from the set of historical        market scenarios structured to comprise calculated changes to        the set of market factors during a rolling window period.-   504. The apparatus of embodiment 503, further, comprising:-   the instructions to calculate a change to a market factor during a    rolling window period are structured to comprise instructions to:    -   determine, via at least one processor, the delta between values        of the market factor at a beginning time point and an ending        time point of the rolling window period.-   505. The apparatus of embodiment 504, further, comprising:-   the processor-executable instructions structured as:    -   determine, via at least one processor, that historical data for        the market factor during the rolling window period is        unavailable for a time point; and    -   impute, via at least one processor, the unavailable historical        data for the time point using a machine learning method.-   506. The apparatus of embodiment 503, further, comprising:-   the rolling window period length is structured to be equal to the    time period length.-   507. The apparatus of embodiment 502, further, comprising:-   the set of time period buckets is structured to have an equal fixed    length for each time period bucket.-   508. The apparatus of embodiment 502, further, comprising:-   the set of time period buckets is structured to have a variable    length for each time period bucket, the variable length for each    time period bucket determined by judging the overall goodness of fit    between the set of simulated market scenarios and the set of    historical market scenarios.-   509. The apparatus of embodiment 502, further, comprising:-   the instructions to train a deep learning neural network for a time    period bucket using the associated subset of historical market    scenarios are structured to comprise instructions to:    -   select, via at least one processor, a historical market scenario        from the associated subset of historical market scenarios; and    -   train, via at least one processor, the deep learning neural        network for the time period bucket on the selected historical        market scenario using a variational autoencoder.-   510. The apparatus of embodiment 509, further, comprising:-   the deep learning neural network for the time period bucket is    trained to generate a set of Gaussian mixture latent variables.-   511. The apparatus of embodiment 510, further, comprising:-   the instructions to generate simulated market scenarios for the time    period bucket, using the trained deep learning neural network    associated with the time period bucket, are structured to comprise    instructions to:    -   generate, via at least one processor, a set of random values for        the set of Gaussian mixture latent variables; and    -   generate a simulated market scenario, from the simulated market        scenarios for the time period bucket, from the generated set of        random values using a neural network decoder of the trained deep        learning neural network associated with the time period bucket.-   512. The apparatus of embodiment 501, further, comprising:-   a filter in the set of filters is configured as a set of customized    market factors from the set of market factors and a range of    allowable values for each customized market factor from the set of    customized market factors.-   513. The apparatus of embodiment 512, further, comprising:-   the instructions to filter the set of simulated market scenarios    based on the set of filters are structured to comprise instructions    to determine a set of filtered simulated market scenarios having    simulated market factor values that fall within the range of    allowable values for each customized market factors from the set of    customized market factors.-   514. The apparatus of embodiment 501, further, comprising:-   a filter in the set of filters is configured as a business cycle    identifier and a business cycle weight associated with the business    cycle identifier.-   515. The apparatus of embodiment 514, further, comprising:-   the processor-executable instructions structured as:    -   calculate, via at least one processor, a weighted expected        portfolio return for the portfolio as a weighted average of        calculated expected portfolio returns for a set of business        cycle identifiers, the set of business cycle identifiers        including the business cycle identifier, the calculated expected        portfolio return associated with the business cycle identifier        weighted in accordance with the business cycle weight.-   516. A machine learning portfolio return computation engine    processor-readable, non-transient medium, comprising    processor-executable instructions structured as:    -   obtain, via at least one processor, a portfolio return        computation request datastructure, the portfolio return        computation request datastructure structured to specify a set of        simulated market scenarios and a set of filters, the set of        simulated market scenarios generated using a set of deep        learning neural networks, each simulated market scenario in the        set of simulated market scenarios structured to comprise a set        of simulated market factor values corresponding to a set of        market factors;    -   determine, via at least one processor, a set of constituent        portfolio securities of a portfolio, each constituent portfolio        security in the set of constituent portfolio securities        associated with a portfolio security weight of the respective        constituent portfolio security in the portfolio;    -   filter, via at least one processor, the set of simulated market        scenarios based on the set of filters to determine a set of        filtered simulated market scenarios having simulated market        factor values that fall within the range of allowable values for        each filter in the set of filters;    -   retrieve, via at least one processor, a set of expected returns        for the set of constituent portfolio securities of the portfolio        for the set of filtered simulated market scenarios;    -   calculate, via at least one processor, for each constituent        portfolio security in the set of constituent portfolio        securities, an expected constituent portfolio security return        for the set of filtered simulated market scenarios as an average        of expected returns in the set of expected returns of the        respective constituent portfolio security; and    -   calculate, via at least one processor, an expected portfolio        return for the set of filtered simulated market scenarios as a        weighted average of the calculated expected constituent        portfolio security returns for the set of filtered simulated        market scenarios, an expected constituent portfolio security        return weighted in accordance with the portfolio security weight        of the associated portfolio security.-   517. The medium of embodiment 516, further, comprising:-   the instructions to generate the set of simulated market scenarios    using the set of deep learning neural networks are structured to    comprise instructions to:    -   determine, via at least one processor, a set of historical        market scenarios and a set of time period buckets;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a subset of        historical market scenarios, from the set of historical market        scenarios, associated with the respective time period bucket;    -   train, via at least one processor, for each time period bucket        from the set of time period buckets, a deep learning neural        network, from the set of deep learning neural networks, using        the subset of historical market scenarios associated with the        respective time period bucket;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a number of        simulated market scenarios to generate using the trained deep        learning neural network associated with the respective time        period bucket; and    -   generate, via at least one processor, for each time period        bucket from the set of time period buckets, the determined        number of simulated market scenarios for the respective time        period bucket, using the trained deep learning neural network        associated with the respective time period bucket.-   518. The medium of embodiment 517, further, comprising:-   the instructions to determine the set of historical market scenarios    are structured to comprise instructions to:    -   determine, via at least one processor, a historical data set, a        rolling window period length, and the set of market factors;    -   determine, via at least one processor, a set of rolling window        periods using the historical data set and the rolling window        period length; and    -   calculate, via at least one processor, for each market factor        from the set of market factors, for each rolling window period        from the set of rolling window periods, a change to the        respective market factor during the respective rolling window        period,        -   each historical market scenario from the set of historical            market scenarios structured to comprise calculated changes            to the set of market factors during a rolling window period.-   519. The medium of embodiment 518, further, comprising:-   the instructions to calculate a change to a market factor during a    rolling window period are structured to comprise instructions to:    -   determine, via at least one processor, the delta between values        of the market factor at a beginning time point and an ending        time point of the rolling window period.-   520. The medium of embodiment 519, further, comprising:-   the processor-executable instructions structured as:    -   determine, via at least one processor, that historical data for        the market factor during the rolling window period is        unavailable for a time point; and    -   impute, via at least one processor, the unavailable historical        data for the time point using a machine learning method.-   521. The medium of embodiment 518, further, comprising:-   the rolling window period length is structured to be equal to the    time period length.-   522. The medium of embodiment 517, further, comprising:-   the set of time period buckets is structured to have an equal fixed    length for each time period bucket.-   523. The medium of embodiment 517, further, comprising:-   the set of time period buckets is structured to have a variable    length for each time period bucket, the variable length for each    time period bucket determined by judging the overall goodness of fit    between the set of simulated market scenarios and the set of    historical market scenarios.-   524. The medium of embodiment 517, further, comprising:-   the instructions to train a deep learning neural network for a time    period bucket using the associated subset of historical market    scenarios are structured to comprise instructions to:    -   select, via at least one processor, a historical market scenario        from the associated subset of historical market scenarios; and    -   train, via at least one processor, the deep learning neural        network for the time period bucket on the selected historical        market scenario using a variational autoencoder.-   525. The medium of embodiment 524, further, comprising:-   the deep learning neural network for the time period bucket is    trained to generate a set of Gaussian mixture latent variables.-   526. The medium of embodiment 525, further, comprising:-   the instructions to generate simulated market scenarios for the time    period bucket, using the trained deep learning neural network    associated with the time period bucket, are structured to comprise    instructions to:    -   generate, via at least one processor, a set of random values for        the set of Gaussian mixture latent variables; and    -   generate a simulated market scenario, from the simulated market        scenarios for the time period bucket, from the generated set of        random values using a neural network decoder of the trained deep        learning neural network associated with the time period bucket.-   527. The medium of embodiment 516, further, comprising:-   a filter in the set of filters is configured as a set of customized    market factors from the set of market factors and a range of    allowable values for each customized market factor from the set of    customized market factors.-   528. The medium of embodiment 527, further, comprising:-   the instructions to filter the set of simulated market scenarios    based on the set of filters are structured to comprise instructions    to determine a set of filtered simulated market scenarios having    simulated market factor values that fall within the range of    allowable values for each customized market factors from the set of    customized market factors.-   529. The medium of embodiment 516, further, comprising:-   a filter in the set of filters is configured as a business cycle    identifier and a business cycle weight associated with the business    cycle identifier.-   530. The medium of embodiment 529, further, comprising:-   the processor-executable instructions structured as:    -   calculate, via at least one processor, a weighted expected        portfolio return for the portfolio as a weighted average of        calculated expected portfolio returns for a set of business        cycle identifiers, the set of business cycle identifiers        including the business cycle identifier, the calculated expected        portfolio return associated with the business cycle identifier        weighted in accordance with the business cycle weight.-   531. A machine learning portfolio return computation engine    processor-implemented system, comprising:-   means to process processor-executable instructions;-   means to issue processor-issuable instructions from a    processor-executable component collection via the means to process    processor-executable instructions, the processor-issuable    instructions structured as:    -   obtain, via at least one processor, a portfolio return        computation request datastructure, the portfolio return        computation request datastructure structured to specify a set of        simulated market scenarios and a set of filters, the set of        simulated market scenarios generated using a set of deep        learning neural networks, each simulated market scenario in the        set of simulated market scenarios structured to comprise a set        of simulated market factor values corresponding to a set of        market factors;    -   determine, via at least one processor, a set of constituent        portfolio securities of a portfolio, each constituent portfolio        security in the set of constituent portfolio securities        associated with a portfolio security weight of the respective        constituent portfolio security in the portfolio;    -   filter, via at least one processor, the set of simulated market        scenarios based on the set of filters to determine a set of        filtered simulated market scenarios having simulated market        factor values that fall within the range of allowable values for        each filter in the set of filters;    -   retrieve, via at least one processor, a set of expected returns        for the set of constituent portfolio securities of the portfolio        for the set of filtered simulated market scenarios;    -   calculate, via at least one processor, for each constituent        portfolio security in the set of constituent portfolio        securities, an expected constituent portfolio security return        for the set of filtered simulated market scenarios as an average        of expected returns in the set of expected returns of the        respective constituent portfolio security; and    -   calculate, via at least one processor, an expected portfolio        return for the set of filtered simulated market scenarios as a        weighted average of the calculated expected constituent        portfolio security returns for the set of filtered simulated        market scenarios, an expected constituent portfolio security        return weighted in accordance with the portfolio security weight        of the associated portfolio security.-   532. The system of embodiment 531, further, comprising:-   the instructions to generate the set of simulated market scenarios    using the set of deep learning neural networks are structured to    comprise instructions to:    -   determine, via at least one processor, a set of historical        market scenarios and a set of time period buckets;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a subset of        historical market scenarios, from the set of historical market        scenarios, associated with the respective time period bucket;    -   train, via at least one processor, for each time period bucket        from the set of time period buckets, a deep learning neural        network, from the set of deep learning neural networks, using        the subset of historical market scenarios associated with the        respective time period bucket;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a number of        simulated market scenarios to generate using the trained deep        learning neural network associated with the respective time        period bucket; and    -   generate, via at least one processor, for each time period        bucket from the set of time period buckets, the determined        number of simulated market scenarios for the respective time        period bucket, using the trained deep learning neural network        associated with the respective time period bucket.-   533. The system of embodiment 532, further, comprising:-   the instructions to determine the set of historical market scenarios    are structured to comprise instructions to:    -   determine, via at least one processor, a historical data set, a        rolling window period length, and the set of market factors;    -   determine, via at least one processor, a set of rolling window        periods using the historical data set and the rolling window        period length; and    -   calculate, via at least one processor, for each market factor        from the set of market factors, for each rolling window period        from the set of rolling window periods, a change to the        respective market factor during the respective rolling window        period,        -   each historical market scenario from the set of historical            market scenarios structured to comprise calculated changes            to the set of market factors during a rolling window period.-   534. The system of embodiment 533, further, comprising:-   the instructions to calculate a change to a market factor during a    rolling window period are structured to comprise instructions to:    -   determine, via at least one processor, the delta between values        of the market factor at a beginning time point and an ending        time point of the rolling window period.-   535. The system of embodiment 534, further, comprising:-   the processor-executable instructions structured as:    -   determine, via at least one processor, that historical data for        the market factor during the rolling window period is        unavailable for a time point; and    -   impute, via at least one processor, the unavailable historical        data for the time point using a machine learning method.-   536. The system of embodiment 533, further, comprising:-   the rolling window period length is structured to be equal to the    time period length.-   537. The system of embodiment 532, further, comprising:-   the set of time period buckets is structured to have an equal fixed    length for each time period bucket.-   538. The system of embodiment 532, further, comprising:-   the set of time period buckets is structured to have a variable    length for each time period bucket, the variable length for each    time period bucket determined by judging the overall goodness of fit    between the set of simulated market scenarios and the set of    historical market scenarios.-   539. The system of embodiment 532, further, comprising:-   the instructions to train a deep learning neural network for a time    period bucket using the associated subset of historical market    scenarios are structured to comprise instructions to:    -   select, via at least one processor, a historical market scenario        from the associated subset of historical market scenarios; and    -   train, via at least one processor, the deep learning neural        network for the time period bucket on the selected historical        market scenario using a variational autoencoder.-   540. The system of embodiment 539, further, comprising:-   the deep learning neural network for the time period bucket is    trained to generate a set of Gaussian mixture latent variables.-   541. The system of embodiment 540, further, comprising:-   the instructions to generate simulated market scenarios for the time    period bucket, using the trained deep learning neural network    associated with the time period bucket, are structured to comprise    instructions to:    -   generate, via at least one processor, a set of random values for        the set of Gaussian mixture latent variables; and    -   generate a simulated market scenario, from the simulated market        scenarios for the time period bucket, from the generated set of        random values using a neural network decoder of the trained deep        learning neural network associated with the time period bucket.-   542. The system of embodiment 531, further, comprising:-   a filter in the set of filters is configured as a set of customized    market factors from the set of market factors and a range of    allowable values for each customized market factor from the set of    customized market factors.-   543. The system of embodiment 542, further, comprising:-   the instructions to filter the set of simulated market scenarios    based on the set of filters are structured to comprise instructions    to determine a set of filtered simulated market scenarios having    simulated market factor values that fall within the range of    allowable values for each customized market factors from the set of    customized market factors.-   544. The system of embodiment 531, further, comprising:-   a filter in the set of filters is configured as a business cycle    identifier and a business cycle weight associated with the business    cycle identifier.-   545. The system of embodiment 544, further, comprising:-   the processor-executable instructions structured as:    -   calculate, via at least one processor, a weighted expected        portfolio return for the portfolio as a weighted average of        calculated expected portfolio returns for a set of business        cycle identifiers, the set of business cycle identifiers        including the business cycle identifier, the calculated expected        portfolio return associated with the business cycle identifier        weighted in accordance with the business cycle weight.-   546. A machine learning portfolio return computation engine    processor-implemented process, comprising executing    processor-executable instructions to:    -   obtain, via at least one processor, a portfolio return        computation request datastructure, the portfolio return        computation request datastructure structured to specify a set of        simulated market scenarios and a set of filters, the set of        simulated market scenarios generated using a set of deep        learning neural networks, each simulated market scenario in the        set of simulated market scenarios structured to comprise a set        of simulated market factor values corresponding to a set of        market factors;    -   determine, via at least one processor, a set of constituent        portfolio securities of a portfolio, each constituent portfolio        security in the set of constituent portfolio securities        associated with a portfolio security weight of the respective        constituent portfolio security in the portfolio;    -   filter, via at least one processor, the set of simulated market        scenarios based on the set of filters to determine a set of        filtered simulated market scenarios having simulated market        factor values that fall within the range of allowable values for        each filter in the set of filters;    -   retrieve, via at least one processor, a set of expected returns        for the set of constituent portfolio securities of the portfolio        for the set of filtered simulated market scenarios;    -   calculate, via at least one processor, for each constituent        portfolio security in the set of constituent portfolio        securities, an expected constituent portfolio security return        for the set of filtered simulated market scenarios as an average        of expected returns in the set of expected returns of the        respective constituent portfolio security; and    -   calculate, via at least one processor, an expected portfolio        return for the set of filtered simulated market scenarios as a        weighted average of the calculated expected constituent        portfolio security returns for the set of filtered simulated        market scenarios, an expected constituent portfolio security        return weighted in accordance with the portfolio security weight        of the associated portfolio security.-   547. The process of embodiment 546, further, comprising:-   the instructions to generate the set of simulated market scenarios    using the set of deep learning neural networks are structured to    comprise instructions to:    -   determine, via at least one processor, a set of historical        market scenarios and a set of time period buckets;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a subset of        historical market scenarios, from the set of historical market        scenarios, associated with the respective time period bucket;    -   train, via at least one processor, for each time period bucket        from the set of time period buckets, a deep learning neural        network, from the set of deep learning neural networks, using        the subset of historical market scenarios associated with the        respective time period bucket;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a number of        simulated market scenarios to generate using the trained deep        learning neural network associated with the respective time        period bucket; and    -   generate, via at least one processor, for each time period        bucket from the set of time period buckets, the determined        number of simulated market scenarios for the respective time        period bucket, using the trained deep learning neural network        associated with the respective time period bucket.-   548. The process of embodiment 547, further, comprising:-   the instructions to determine the set of historical market scenarios    are structured to comprise instructions to:    -   determine, via at least one processor, a historical data set, a        rolling window period length, and the set of market factors;    -   determine, via at least one processor, a set of rolling window        periods using the historical data set and the rolling window        period length; and    -   calculate, via at least one processor, for each market factor        from the set of market factors, for each rolling window period        from the set of rolling window periods, a change to the        respective market factor during the respective rolling window        period,        -   each historical market scenario from the set of historical            market scenarios structured to comprise calculated changes            to the set of market factors during a rolling window period.-   549. The process of embodiment 548, further, comprising:-   the instructions to calculate a change to a market factor during a    rolling window period are structured to comprise instructions to:    -   determine, via at least one processor, the delta between values        of the market factor at a beginning time point and an ending        time point of the rolling window period.-   550. The process of embodiment 549, further, comprising:-   the processor-executable instructions structured as:    -   determine, via at least one processor, that historical data for        the market factor during the rolling window period is        unavailable for a time point; and    -   impute, via at least one processor, the unavailable historical        data for the time point using a machine learning method.-   551. The process of embodiment 548, further, comprising:-   the rolling window period length is structured to be equal to the    time period length.-   552. The process of embodiment 547, further, comprising:-   the set of time period buckets is structured to have an equal fixed    length for each time period bucket.-   553. The process of embodiment 547, further, comprising:-   the set of time period buckets is structured to have a variable    length for each time period bucket, the variable length for each    time period bucket determined by judging the overall goodness of fit    between the set of simulated market scenarios and the set of    historical market scenarios.-   554. The process of embodiment 547, further, comprising:-   the instructions to train a deep learning neural network for a time    period bucket using the associated subset of historical market    scenarios are structured to comprise instructions to:    -   select, via at least one processor, a historical market scenario        from the associated subset of historical market scenarios; and    -   train, via at least one processor, the deep learning neural        network for the time period bucket on the selected historical        market scenario using a variational autoencoder.-   555. The process of embodiment 554, further, comprising:-   the deep learning neural network for the time period bucket is    trained to generate a set of Gaussian mixture latent variables.-   556. The process of embodiment 555, further, comprising:-   the instructions to generate simulated market scenarios for the time    period bucket, using the trained deep learning neural network    associated with the time period bucket, are structured to comprise    instructions to:    -   generate, via at least one processor, a set of random values for        the set of Gaussian mixture latent variables; and    -   generate a simulated market scenario, from the simulated market        scenarios for the time period bucket, from the generated set of        random values using a neural network decoder of the trained deep        learning neural network associated with the time period bucket.-   557. The process of embodiment 546, further, comprising:-   a filter in the set of filters is configured as a set of customized    market factors from the set of market factors and a range of    allowable values for each customized market factor from the set of    customized market factors.-   558. The process of embodiment 557, further, comprising:-   the instructions to filter the set of simulated market scenarios    based on the set of filters are structured to comprise instructions    to determine a set of filtered simulated market scenarios having    simulated market factor values that fall within the range of    allowable values for each customized market factors from the set of    customized market factors.-   559. The process of embodiment 546, further, comprising:-   a filter in the set of filters is configured as a business cycle    identifier and a business cycle weight associated with the business    cycle identifier.-   560. The process of embodiment 559, further, comprising:-   the processor-executable instructions structured as:    -   calculate, via at least one processor, a weighted expected        portfolio return for the portfolio as a weighted average of        calculated expected portfolio returns for a set of business        cycle identifiers, the set of business cycle identifiers        including the business cycle identifier, the calculated expected        portfolio return associated with the business cycle identifier        weighted in accordance with the business cycle weight.-   601. A machine learning portfolio return computation engine    apparatus, comprising:-   a memory;-   a component collection in the memory;-   a processor disposed in communication with the memory and configured    to issue a plurality of processor-executable instructions from the    component collection, the processor-executable instructions    structured as:    -   obtain, via at least one processor, a portfolio return        computation request datastructure, the portfolio return        computation request datastructure structured to specify a set of        simulated market scenarios and a set of filters, the set of        simulated market scenarios generated using a set of        multi-variate mixture datastructures, each simulated market        scenario in the set of simulated market scenarios structured to        comprise a set of simulated market factor values corresponding        to a set of market factors;    -   determine, via at least one processor, a set of constituent        portfolio securities of a portfolio, each constituent portfolio        security in the set of constituent portfolio securities        associated with a portfolio security weight of the respective        constituent portfolio security in the portfolio;    -   filter, via at least one processor, the set of simulated market        scenarios based on the set of filters to determine a set of        filtered simulated market scenarios having simulated market        factor values that fall within the range of allowable values for        each filter in the set of filters;    -   retrieve, via at least one processor, a set of expected returns        for the set of constituent portfolio securities of the portfolio        for the set of filtered simulated market scenarios;    -   calculate, via at least one processor, for each constituent        portfolio security in the set of constituent portfolio        securities, an expected constituent portfolio security return        for the set of filtered simulated market scenarios as an average        of expected returns in the set of expected returns of the        respective constituent portfolio security; and    -   calculate, via at least one processor, an expected portfolio        return for the set of filtered simulated market scenarios as a        weighted average of the calculated expected constituent        portfolio security returns for the set of filtered simulated        market scenarios, an expected constituent portfolio security        return weighted in accordance with the portfolio security weight        of the associated portfolio security.-   602. The apparatus of embodiment 601, further, comprising:-   the instructions to generate the set of simulated market scenarios    using the set of multi-variate mixture datastructures are structured    to comprise instructions to    -   determine, via at least one processor, a set of historical        market scenarios and a set of time period buckets;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a subset of        historical market scenarios, from the set of historical market        scenarios, associated with the respective time period bucket;    -   train, via at least one processor, for each time period bucket        from the set of time period buckets, a multi-variate mixture        datastructure, from the set of multi-variate mixture        datastructures, using the subset of historical market scenarios        associated with the respective time period bucket;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a number of        simulated market scenarios to generate using the trained        multi-variate mixture datastructure associated with the        respective time period bucket; and    -   generate, via at least one processor, for each time period        bucket from the set of time period buckets, the determined        number of simulated market scenarios for the respective time        period bucket, using the trained multi-variate mixture        datastructure associated with the respective time period bucket.-   603. The apparatus of embodiment 602, further, comprising:-   the instructions to determine the set of historical market scenarios    are structured to comprise instructions to:    -   determine, via at least one processor, a historical data set and        the set of market factors;    -   determine, via at least one processor, a set of rolling window        periods for the historical data set; and    -   calculate, via at least one processor, for each market factor        from the set of market factors, for each rolling window period        from the set of rolling window periods, a change to the        respective market factor during the respective rolling window        period,        -   each historical market scenario from the set of historical            market scenarios structured to comprise calculated changes            to the set of market factors during a rolling window period.-   604. The apparatus of embodiment 603, further, comprising:-   the instructions to calculate a change to a market factor during a    rolling window period are structured to comprise instructions to:    -   determine, via at least one processor, the delta between values        of the market factor at two time point of the rolling window        period.-   605. The apparatus of embodiment 604, further, comprising:-   the processor-executable instructions structured as:    -   determine, via at least one processor, that historical data for        the market factor during the rolling window period is        unavailable for a time point; and    -   impute, via at least one processor, the unavailable historical        data for the time point using a k-Nearest Neighbors method.-   606. The apparatus of embodiment 603, further, comprising:-   the length of a rolling window period is structured to be equal to    the time period length.-   607. The apparatus of embodiment 602, further, comprising:-   the set of time period buckets is structured to have a fixed length    for each time period bucket.-   608. The apparatus of embodiment 602, further, comprising:-   the set of time period buckets is structured to have variable    lengths, the variable length for each time period bucket reflective    of changes in volatilities and correlations of the set of historical    market scenarios.-   609. The apparatus of embodiment 603, further, comprising:-   the instructions to train a multi-variate mixture datastructure for    a time period bucket using the associated subset of historical    market scenarios are structured to comprise instructions to:    -   determine, via at least one processor, for each market factor        from the set of market factors, a distribution to use for the        respective market factor for the time period bucket;    -   fit, via at least one processor, for each market factor from the        set of market factors, the distribution to use for the        respective market factor for the time period bucket using the        associated subset of historical market scenarios;    -   determine, via at least one processor, a copula for the set of        market factors for the time period bucket; and    -   train, via at least one processor, the multi-variate mixture        datastructure for the time period bucket using the fitted        distributions and the copula for the set of market factors.-   610. The apparatus of embodiment 609, further, comprising:-   the instructions to fit the distribution to use for a market factor    for the time period bucket using the associated subset of historical    market scenarios are structured to comprise instructions to    calculate the mean of the market factor's values in the associated    subset of historical market scenarios.-   611. The apparatus of embodiment 602, further, comprising:-   the instructions to generate simulated market scenarios for a time    period bucket, using the trained multi-variate mixture datastructure    associated with the time period bucket, are structured to comprise    instructions to:    -   generate a simulated market scenario, from the simulated market        scenarios for the time period bucket, by sampling the trained        multi-variate mixture datastructure associated with the time        period bucket.-   612. The apparatus of embodiment 601, further, comprising:-   a filter in the set of filters is configured as a set of customized    market factors from the set of market factors and a range of    allowable values for each customized market factor from the set of    customized market factors.-   613. The apparatus of embodiment 612, further, comprising:-   the instructions to filter the set of simulated market scenarios    based on the set of filters are structured to comprise instructions    to determine a set of filtered simulated market scenarios having    simulated market factor values that fall within the range of    allowable values for each customized market factors from the set of    customized market factors.-   614. The apparatus of embodiment 601, further, comprising:-   a filter in the set of filters is configured as a business cycle    identifier and a business cycle weight associated with the business    cycle identifier.-   615. The apparatus of embodiment 614, further, comprising:-   the processor-executable instructions structured as:    -   calculate, via at least one processor, a weighted expected        portfolio return for the portfolio as a weighted average of        calculated expected portfolio returns for a set of business        cycle identifiers, the set of business cycle identifiers        including the business cycle identifier, the calculated expected        portfolio return associated with the business cycle identifier        weighted in accordance with the business cycle weight.-   616. A machine learning portfolio return computation engine    processor-readable, non-transient medium, comprising    processor-executable instructions structured as:    -   obtain, via at least one processor, a portfolio return        computation request datastructure, the portfolio return        computation request datastructure structured to specify a set of        simulated market scenarios and a set of filters, the set of        simulated market scenarios generated using a set of        multi-variate mixture datastructures, each simulated market        scenario in the set of simulated market scenarios structured to        comprise a set of simulated market factor values corresponding        to a set of market factors;    -   determine, via at least one processor, a set of constituent        portfolio securities of a portfolio, each constituent portfolio        security in the set of constituent portfolio securities        associated with a portfolio security weight of the respective        constituent portfolio security in the portfolio;    -   filter, via at least one processor, the set of simulated market        scenarios based on the set of filters to determine a set of        filtered simulated market scenarios having simulated market        factor values that fall within the range of allowable values for        each filter in the set of filters;    -   retrieve, via at least one processor, a set of expected returns        for the set of constituent portfolio securities of the portfolio        for the set of filtered simulated market scenarios;    -   calculate, via at least one processor, for each constituent        portfolio security in the set of constituent portfolio        securities, an expected constituent portfolio security return        for the set of filtered simulated market scenarios as an average        of expected returns in the set of expected returns of the        respective constituent portfolio security; and    -   calculate, via at least one processor, an expected portfolio        return for the set of filtered simulated market scenarios as a        weighted average of the calculated expected constituent        portfolio security returns for the set of filtered simulated        market scenarios, an expected constituent portfolio security        return weighted in accordance with the portfolio security weight        of the associated portfolio security.-   617. The medium of embodiment 616, further, comprising:-   the instructions to generate the set of simulated market scenarios    using the set of multi-variate mixture datastructures are structured    to comprise instructions to    -   determine, via at least one processor, a set of historical        market scenarios and a set of time period buckets;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a subset of        historical market scenarios, from the set of historical market        scenarios, associated with the respective time period bucket;    -   train, via at least one processor, for each time period bucket        from the set of time period buckets, a multi-variate mixture        datastructure, from the set of multi-variate mixture        datastructures, using the subset of historical market scenarios        associated with the respective time period bucket;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a number of        simulated market scenarios to generate using the trained        multi-variate mixture datastructure associated with the        respective time period bucket; and    -   generate, via at least one processor, for each time period        bucket from the set of time period buckets, the determined        number of simulated market scenarios for the respective time        period bucket, using the trained multi-variate mixture        datastructure associated with the respective time period bucket.-   618. The medium of embodiment 617, further, comprising:-   the instructions to determine the set of historical market scenarios    are structured to comprise instructions to:    -   determine, via at least one processor, a historical data set and        the set of market factors;    -   determine, via at least one processor, a set of rolling window        periods for the historical data set; and    -   calculate, via at least one processor, for each market factor        from the set of market factors, for each rolling window period        from the set of rolling window periods, a change to the        respective market factor during the respective rolling window        period,        -   each historical market scenario from the set of historical            market scenarios structured to comprise calculated changes            to the set of market factors during a rolling window period.-   619. The medium of embodiment 618, further, comprising:-   the instructions to calculate a change to a market factor during a    rolling window period are structured to comprise instructions to:    -   determine, via at least one processor, the delta between values        of the market factor at two time point of the rolling window        period.-   620. The medium of embodiment 619, further, comprising:-   the processor-executable instructions structured as:    -   determine, via at least one processor, that historical data for        the market factor during the rolling window period is        unavailable for a time point; and    -   impute, via at least one processor, the unavailable historical        data for the time point using a k-Nearest Neighbors method.-   621. The medium of embodiment 618, further, comprising:-   the length of a rolling window period is structured to be equal to    the time period length.-   622. The medium of embodiment 617, further, comprising:-   the set of time period buckets is structured to have a fixed length    for each time period bucket.-   623. The medium of embodiment 617, further, comprising:-   the set of time period buckets is structured to have variable    lengths, the variable length for each time period bucket reflective    of changes in volatilities and correlations of the set of historical    market scenarios.-   624. The medium of embodiment 618, further, comprising:-   the instructions to train a multi-variate mixture datastructure for    a time period bucket using the associated subset of historical    market scenarios are structured to comprise instructions to:    -   determine, via at least one processor, for each market factor        from the set of market factors, a distribution to use for the        respective market factor for the time period bucket;    -   fit, via at least one processor, for each market factor from the        set of market factors, the distribution to use for the        respective market factor for the time period bucket using the        associated subset of historical market scenarios;    -   determine, via at least one processor, a copula for the set of        market factors for the time period bucket; and    -   train, via at least one processor, the multi-variate mixture        datastructure for the time period bucket using the fitted        distributions and the copula for the set of market factors.-   625. The medium of embodiment 624, further, comprising:-   the instructions to fit the distribution to use for a market factor    for the time period bucket using the associated subset of historical    market scenarios are structured to comprise instructions to    calculate the mean of the market factor's values in the associated    subset of historical market scenarios.-   626. The medium of embodiment 617, further, comprising:-   the instructions to generate simulated market scenarios for a time    period bucket, using the trained multi-variate mixture datastructure    associated with the time period bucket, are structured to comprise    instructions to:    -   generate a simulated market scenario, from the simulated market        scenarios for the time period bucket, by sampling the trained        multi-variate mixture datastructure associated with the time        period bucket.-   627. The medium of embodiment 616, further, comprising:-   a filter in the set of filters is configured as a set of customized    market factors from the set of market factors and a range of    allowable values for each customized market factor from the set of    customized market factors.-   628. The medium of embodiment 627, further, comprising:-   the instructions to filter the set of simulated market scenarios    based on the set of filters are structured to comprise instructions    to determine a set of filtered simulated market scenarios having    simulated market factor values that fall within the range of    allowable values for each customized market factors from the set of    customized market factors.-   629. The medium of embodiment 616, further, comprising:-   a filter in the set of filters is configured as a business cycle    identifier and a business cycle weight associated with the business    cycle identifier.-   630. The medium of embodiment 629, further, comprising:-   the processor-executable instructions structured as:    -   calculate, via at least one processor, a weighted expected        portfolio return for the portfolio as a weighted average of        calculated expected portfolio returns for a set of business        cycle identifiers, the set of business cycle identifiers        including the business cycle identifier, the calculated expected        portfolio return associated with the business cycle identifier        weighted in accordance with the business cycle weight.-   631. A machine learning portfolio return computation engine    processor-implemented system, comprising:-   means to process processor-executable instructions;-   means to issue processor-issuable instructions from a    processor-executable component collection via the means to process    processor-executable instructions, the processor-issuable    instructions structured as:    -   obtain, via at least one processor, a portfolio return        computation request datastructure, the portfolio return        computation request datastructure structured to specify a set of        simulated market scenarios and a set of filters, the set of        simulated market scenarios generated using a set of        multi-variate mixture datastructures, each simulated market        scenario in the set of simulated market scenarios structured to        comprise a set of simulated market factor values corresponding        to a set of market factors;    -   determine, via at least one processor, a set of constituent        portfolio securities of a portfolio, each constituent portfolio        security in the set of constituent portfolio securities        associated with a portfolio security weight of the respective        constituent portfolio security in the portfolio;    -   filter, via at least one processor, the set of simulated market        scenarios based on the set of filters to determine a set of        filtered simulated market scenarios having simulated market        factor values that fall within the range of allowable values for        each filter in the set of filters;    -   retrieve, via at least one processor, a set of expected returns        for the set of constituent portfolio securities of the portfolio        for the set of filtered simulated market scenarios;    -   calculate, via at least one processor, for each constituent        portfolio security in the set of constituent portfolio        securities, an expected constituent portfolio security return        for the set of filtered simulated market scenarios as an average        of expected returns in the set of expected returns of the        respective constituent portfolio security; and    -   calculate, via at least one processor, an expected portfolio        return for the set of filtered simulated market scenarios as a        weighted average of the calculated expected constituent        portfolio security returns for the set of filtered simulated        market scenarios, an expected constituent portfolio security        return weighted in accordance with the portfolio security weight        of the associated portfolio security.-   632. The system of embodiment 631, further, comprising:-   the instructions to generate the set of simulated market scenarios    using the set of multi-variate mixture datastructures are structured    to comprise instructions to    -   determine, via at least one processor, a set of historical        market scenarios and a set of time period buckets;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a subset of        historical market scenarios, from the set of historical market        scenarios, associated with the respective time period bucket;    -   train, via at least one processor, for each time period bucket        from the set of time period buckets, a multi-variate mixture        datastructure, from the set of multi-variate mixture        datastructures, using the subset of historical market scenarios        associated with the respective time period bucket;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a number of        simulated market scenarios to generate using the trained        multi-variate mixture datastructure associated with the        respective time period bucket; and    -   generate, via at least one processor, for each time period        bucket from the set of time period buckets, the determined        number of simulated market scenarios for the respective time        period bucket, using the trained multi-variate mixture        datastructure associated with the respective time period bucket.-   633. The system of embodiment 632, further, comprising:-   the instructions to determine the set of historical market scenarios    are structured to comprise instructions to:    -   determine, via at least one processor, a historical data set and        the set of market factors;    -   determine, via at least one processor, a set of rolling window        periods for the historical data set; and    -   calculate, via at least one processor, for each market factor        from the set of market factors, for each rolling window period        from the set of rolling window periods, a change to the        respective market factor during the respective rolling window        period,        -   each historical market scenario from the set of historical            market scenarios structured to comprise calculated changes            to the set of market factors during a rolling window period.-   634. The system of embodiment 633, further, comprising:-   the instructions to calculate a change to a market factor during a    rolling window period are structured to comprise instructions to:    -   determine, via at least one processor, the delta between values        of the market factor at two time point of the rolling window        period.-   635. The system of embodiment 634, further, comprising:-   the processor-executable instructions structured as:    -   determine, via at least one processor, that historical data for        the market factor during the rolling window period is        unavailable for a time point; and    -   impute, via at least one processor, the unavailable historical        data for the time point using a k-Nearest Neighbors method.-   636. The system of embodiment 633, further, comprising:-   the length of a rolling window period is structured to be equal to    the time period length.-   637. The system of embodiment 632, further, comprising:-   the set of time period buckets is structured to have a fixed length    for each time period bucket.-   638. The system of embodiment 632, further, comprising:-   the set of time period buckets is structured to have variable    lengths, the variable length for each time period bucket reflective    of changes in volatilities and correlations of the set of historical    market scenarios.-   639. The system of embodiment 633, further, comprising:-   the instructions to train a multi-variate mixture datastructure for    a time period bucket using the associated subset of historical    market scenarios are structured to comprise instructions to:    -   determine, via at least one processor, for each market factor        from the set of market factors, a distribution to use for the        respective market factor for the time period bucket;    -   fit, via at least one processor, for each market factor from the        set of market factors, the distribution to use for the        respective market factor for the time period bucket using the        associated subset of historical market scenarios;    -   determine, via at least one processor, a copula for the set of        market factors for the time period bucket; and    -   train, via at least one processor, the multi-variate mixture        datastructure for the time period bucket using the fitted        distributions and the copula for the set of market factors.-   640. The system of embodiment 639, further, comprising:-   the instructions to fit the distribution to use for a market factor    for the time period bucket using the associated subset of historical    market scenarios are structured to comprise instructions to    calculate the mean of the market factor's values in the associated    subset of historical market scenarios.-   641. The system of embodiment 632, further, comprising:-   the instructions to generate simulated market scenarios for a time    period bucket, using the trained multi-variate mixture datastructure    associated with the time period bucket, are structured to comprise    instructions to:    -   generate a simulated market scenario, from the simulated market        scenarios for the time period bucket, by sampling the trained        multi-variate mixture datastructure associated with the time        period bucket.-   642. The system of embodiment 631, further, comprising:-   a filter in the set of filters is configured as a set of customized    market factors from the set of market factors and a range of    allowable values for each customized market factor from the set of    customized market factors.-   643. The system of embodiment 642, further, comprising:-   the instructions to filter the set of simulated market scenarios    based on the set of filters are structured to comprise instructions    to determine a set of filtered simulated market scenarios having    simulated market factor values that fall within the range of    allowable values for each customized market factors from the set of    customized market factors.-   644. The system of embodiment 631, further, comprising:-   a filter in the set of filters is configured as a business cycle    identifier and a business cycle weight associated with the business    cycle identifier.-   645. The system of embodiment 644, further, comprising:-   the processor-executable instructions structured as:    -   calculate, via at least one processor, a weighted expected        portfolio return for the portfolio as a weighted average of        calculated expected portfolio returns for a set of business        cycle identifiers, the set of business cycle identifiers        including the business cycle identifier, the calculated expected        portfolio return associated with the business cycle identifier        weighted in accordance with the business cycle weight.-   646. A machine learning portfolio return computation engine    processor-implemented process, comprising executing    processor-executable instructions to:    -   obtain, via at least one processor, a portfolio return        computation request datastructure, the portfolio return        computation request datastructure structured to specify a set of        simulated market scenarios and a set of filters, the set of        simulated market scenarios generated using a set of        multi-variate mixture datastructures, each simulated market        scenario in the set of simulated market scenarios structured to        comprise a set of simulated market factor values corresponding        to a set of market factors;    -   determine, via at least one processor, a set of constituent        portfolio securities of a portfolio, each constituent portfolio        security in the set of constituent portfolio securities        associated with a portfolio security weight of the respective        constituent portfolio security in the portfolio;    -   filter, via at least one processor, the set of simulated market        scenarios based on the set of filters to determine a set of        filtered simulated market scenarios having simulated market        factor values that fall within the range of allowable values for        each filter in the set of filters;    -   retrieve, via at least one processor, a set of expected returns        for the set of constituent portfolio securities of the portfolio        for the set of filtered simulated market scenarios;    -   calculate, via at least one processor, for each constituent        portfolio security in the set of constituent portfolio        securities, an expected constituent portfolio security return        for the set of filtered simulated market scenarios as an average        of expected returns in the set of expected returns of the        respective constituent portfolio security; and    -   calculate, via at least one processor, an expected portfolio        return for the set of filtered simulated market scenarios as a        weighted average of the calculated expected constituent        portfolio security returns for the set of filtered simulated        market scenarios, an expected constituent portfolio security        return weighted in accordance with the portfolio security weight        of the associated portfolio security.-   647. The process of embodiment 646, further, comprising:-   the instructions to generate the set of simulated market scenarios    using the set of multi-variate mixture datastructures are structured    to comprise instructions to    -   determine, via at least one processor, a set of historical        market scenarios and a set of time period buckets;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a subset of        historical market scenarios, from the set of historical market        scenarios, associated with the respective time period bucket;    -   train, via at least one processor, for each time period bucket        from the set of time period buckets, a multi-variate mixture        datastructure, from the set of multi-variate mixture        datastructures, using the subset of historical market scenarios        associated with the respective time period bucket;    -   determine, via at least one processor, for each time period        bucket from the set of time period buckets, a number of        simulated market scenarios to generate using the trained        multi-variate mixture datastructure associated with the        respective time period bucket; and    -   generate, via at least one processor, for each time period        bucket from the set of time period buckets, the determined        number of simulated market scenarios for the respective time        period bucket, using the trained multi-variate mixture        datastructure associated with the respective time period bucket.-   648. The process of embodiment 647, further, comprising:-   the instructions to determine the set of historical market scenarios    are structured to comprise instructions to:    -   determine, via at least one processor, a historical data set and        the set of market factors;    -   determine, via at least one processor, a set of rolling window        periods for the historical data set; and    -   calculate, via at least one processor, for each market factor        from the set of market factors, for each rolling window period        from the set of rolling window periods, a change to the        respective market factor during the respective rolling window        period,        -   each historical market scenario from the set of historical            market scenarios structured to comprise calculated changes            to the set of market factors during a rolling window period.-   649. The process of embodiment 648, further, comprising:-   the instructions to calculate a change to a market factor during a    rolling window period are structured to comprise instructions to:    -   determine, via at least one processor, the delta between values        of the market factor at two time point of the rolling window        period.-   650. The process of embodiment 649, further, comprising:-   the processor-executable instructions structured as:    -   determine, via at least one processor, that historical data for        the market factor during the rolling window period is        unavailable for a time point; and    -   impute, via at least one processor, the unavailable historical        data for the time point using a k-Nearest Neighbors method.-   651. The process of embodiment 648, further, comprising:-   the length of a rolling window period is structured to be equal to    the time period length.-   652. The process of embodiment 647, further, comprising:-   the set of time period buckets is structured to have a fixed length    for each time period bucket.-   653. The process of embodiment 647, further, comprising:-   the set of time period buckets is structured to have variable    lengths, the variable length for each time period bucket reflective    of changes in volatilities and correlations of the set of historical    market scenarios.-   654. The process of embodiment 648, further, comprising:-   the instructions to train a multi-variate mixture datastructure for    a time period bucket using the associated subset of historical    market scenarios are structured to comprise instructions to:    -   determine, via at least one processor, for each market factor        from the set of market factors, a distribution to use for the        respective market factor for the time period bucket;    -   fit, via at least one processor, for each market factor from the        set of market factors, the distribution to use for the        respective market factor for the time period bucket using the        associated subset of historical market scenarios;    -   determine, via at least one processor, a copula for the set of        market factors for the time period bucket; and    -   train, via at least one processor, the multi-variate mixture        datastructure for the time period bucket using the fitted        distributions and the copula for the set of market factors.-   655. The process of embodiment 654, further, comprising:-   the instructions to fit the distribution to use for a market factor    for the time period bucket using the associated subset of historical    market scenarios are structured to comprise instructions to    calculate the mean of the market factor's values in the associated    subset of historical market scenarios.-   656. The process of embodiment 647, further, comprising:-   the instructions to generate simulated market scenarios for a time    period bucket, using the trained multi-variate mixture datastructure    associated with the time period bucket, are structured to comprise    instructions to:    -   generate a simulated market scenario, from the simulated market        scenarios for the time period bucket, by sampling the trained        multi-variate mixture datastructure associated with the time        period bucket.-   657. The process of embodiment 646, further, comprising:-   a filter in the set of filters is configured as a set of customized    market factors from the set of market factors and a range of    allowable values for each customized market factor from the set of    customized market factors.-   658. The process of embodiment 657, further, comprising:-   the instructions to filter the set of simulated market scenarios    based on the set of filters are structured to comprise instructions    to determine a set of filtered simulated market scenarios having    simulated market factor values that fall within the range of    allowable values for each customized market factors from the set of    customized market factors.-   659. The process of embodiment 646, further, comprising:-   a filter in the set of filters is configured as a business cycle    identifier and a business cycle weight associated with the business    cycle identifier.-   660. The process of embodiment 659, further, comprising:-   the processor-executable instructions structured as:    -   calculate, via at least one processor, a weighted expected        portfolio return for the portfolio as a weighted average of        calculated expected portfolio returns for a set of business        cycle identifiers, the set of business cycle identifiers        including the business cycle identifier, the calculated expected        portfolio return associated with the business cycle identifier        weighted in accordance with the business cycle weight.-   701. A database calculation engine apparatus, comprising:-   a memory;-   a component collection in the memory;-   a processor disposed in communication with the memory and configured    to issue a plurality of processor-executable instructions from the    component collection, the processor-executable instructions    structured as:    -   obtain, via at least one processor, an asset return metrics        calculation request datastructure, the asset return metrics        calculation request datastructure structured to specify a set of        assets and a set of simulated market scenarios, each simulated        market scenario in the set of simulated market scenarios        structured to comprise a set of simulated market factor values        corresponding to a set of market factors;    -   determine, via at least one processor, a number of sessions to        utilize for calculating asset return metrics data;    -   determine, via at least one processor, an assets range for a        session based on the determined number of sessions to utilize,        the assets range comprising a set of asset database table        records for the set of assets to be processed by the session;    -   create, via at least one processor, an assets batch database        table, the assets batch database table structured to comprise a        set of asset database table records of a specified batch size        from the assets range for the session;    -   create, via at least one processor, a factor simulations batch        database table, the factor simulations batch database table        structured to comprise a set of simulated market factor return        values for the set of asset database table records in the assets        batch database table;    -   create, via at least one processor, a factor exposures batch        database table, the factor exposures batch database table        structured to comprise a set of factor exposure database table        records matching the set of asset database table records in the        assets batch database table; and    -   calculate, via at least one processor, via a parallel SQL query,        expected returns for the set of asset database table records in        the assets batch database table, using the factor simulations        batch database table and the factor exposures batch database        table.-   702. The apparatus of embodiment 701, further, comprising:-   the set of simulated market factor values for a simulated market    scenario is configured as generated using a set of deep learning    neural networks.-   703. The apparatus of embodiment 701, further, comprising:-   the set of simulated market factor values for a simulated market    scenario is configured as generated using a set of multi-variate    mixture datastructures.-   704. The apparatus of embodiment 701, further, comprising:-   the processor-executable instructions structured as:    -   filter, via at least one processor, asset database table records        associated with the set of assets, based on available factor        exposure database table records, using a SQL statement.-   705. The apparatus of embodiment 704, further, comprising:-   the processor-executable instructions structured as:    -   filter, via at least one processor, simulated market scenario        database table records associated with the set of simulated        market scenarios, based on a subset of market factors from the        set of market factors to which the filtered asset database table        records have exposure, using a SQL statement.-   706. The apparatus of embodiment 701, further, comprising:-   the number of sessions to utilize for calculating asset return    metrics data is determined based on the number of available server    processors and a specified degree of parallelism per session.-   707. The apparatus of embodiment 701, further, comprising:-   the assets batch database table, the factor simulations batch    database table, and the factor exposures batch database table are    temporary database tables.-   708. The apparatus of embodiment 704, further, comprising:-   the processor-executable instructions structured as:    -   filter, via at least one processor, at least one of call        schedule database table records and put schedule database table        records based on the filtered asset database table records.-   709. The apparatus of embodiment 708, further, comprising:-   the processor-executable instructions structured as:    -   adjust, via at least one processor, via a parallel SQL query,        the calculated expected returns for the set of asset database        table records in the assets batch database table, based on at        least one of the filtered call schedule database table records        and the filtered put schedule database table records.-   710. The apparatus of embodiment 701, further, comprising:-   the processor-executable instructions structured as:    -   transpose, via at least one processor, the calculated expected        returns for the set of asset database table records in the        assets batch database table into a wide array format; and    -   write, via at least one processor, via a parallel SQL query, the        transposed expected returns to an asset simulation wide table.-   711. The apparatus of embodiment 710, further, comprising:-   the asset simulation wide table formatted to facilitate efficient    calculation of portfolio return metrics; and-   the asset simulation wide table structured to be written to in    parallel by query server processes from a plurality of utilized    sessions.-   712. The apparatus of embodiment 701, further, comprising:-   the processor-executable instructions structured as:    -   calculate, via at least one processor, via a parallel SQL query,        an asset return metric based on the calculated expected returns        for the set of asset database table records in the assets batch        database table;    -   transpose, via at least one processor, the calculated asset        return metric for the set of asset database table records in the        assets batch database table into a wide array format; and    -   write, via at least one processor, via a parallel SQL query, the        transposed asset return metric to an asset simulation wide        table.-   713. The apparatus of embodiment 701, further, comprising:-   the processor-executable instructions structured as:    -   write, via at least one processor, via a parallel SQL query, the        calculated expected returns to an asset measure table.-   714. The apparatus of embodiment 701, further, comprising:-   the processor-executable instructions structured as:    -   calculate, via at least one processor, via a parallel SQL query,        an asset return metric based on the calculated expected returns        for the set of asset database table records in the assets batch        database table; and    -   write, via at least one processor, via a parallel SQL query, the        calculated asset return metric to an asset measure table.-   715. The apparatus of embodiment 714, further, comprising:-   the asset measure table formatted to facilitate efficient    calculation of security return metrics; and-   the asset measure table structured to be written to in parallel by    query server processes from a plurality of utilized sessions.-   716. A database calculation engine processor-readable, non-transient    medium, comprising processor-executable instructions structured as:    -   obtain, via at least one processor, an asset return metrics        calculation request datastructure, the asset return metrics        calculation request datastructure structured to specify a set of        assets and a set of simulated market scenarios, each simulated        market scenario in the set of simulated market scenarios        structured to comprise a set of simulated market factor values        corresponding to a set of market factors;    -   determine, via at least one processor, a number of sessions to        utilize for calculating asset return metrics data;    -   determine, via at least one processor, an assets range for a        session based on the determined number of sessions to utilize,        the assets range comprising a set of asset database table        records for the set of assets to be processed by the session;    -   create, via at least one processor, an assets batch database        table, the assets batch database table structured to comprise a        set of asset database table records of a specified batch size        from the assets range for the session;    -   create, via at least one processor, a factor simulations batch        database table, the factor simulations batch database table        structured to comprise a set of simulated market factor return        values for the set of asset database table records in the assets        batch database table;    -   create, via at least one processor, a factor exposures batch        database table, the factor exposures batch database table        structured to comprise a set of factor exposure database table        records matching the set of asset database table records in the        assets batch database table; and    -   calculate, via at least one processor, via a parallel SQL query,        expected returns for the set of asset database table records in        the assets batch database table, using the factor simulations        batch database table and the factor exposures batch database        table.-   717. The medium of embodiment 716, further, comprising:-   the set of simulated market factor values for a simulated market    scenario is configured as generated using a set of deep learning    neural networks.-   718. The medium of embodiment 716, further, comprising:-   the set of simulated market factor values for a simulated market    scenario is configured as generated using a set of multi-variate    mixture datastructures.-   719. The medium of embodiment 716, further, comprising:-   the processor-executable instructions structured as:    -   filter, via at least one processor, asset database table records        associated with the set of assets, based on available factor        exposure database table records, using a SQL statement.-   720. The medium of embodiment 719, further, comprising:-   the processor-executable instructions structured as:    -   filter, via at least one processor, simulated market scenario        database table records associated with the set of simulated        market scenarios, based on a subset of market factors from the        set of market factors to which the filtered asset database table        records have exposure, using a SQL statement.-   721. The medium of embodiment 716, further, comprising:-   the number of sessions to utilize for calculating asset return    metrics data is determined based on the number of available server    processors and a specified degree of parallelism per session.-   722. The medium of embodiment 716, further, comprising:-   the assets batch database table, the factor simulations batch    database table, and the factor exposures batch database table are    temporary database tables.-   723. The medium of embodiment 719, further, comprising:-   the processor-executable instructions structured as:

filter, via at least one processor, at least one of call scheduledatabase table records and put schedule database table records based onthe filtered asset database table records.

-   724. The medium of embodiment 723, further, comprising:-   the processor-executable instructions structured as:

adjust, via at least one processor, via a parallel SQL query, thecalculated expected returns for the set of asset database table recordsin the assets batch database table, based on at least one of thefiltered call schedule database table records and the filtered putschedule database table records.

-   725. The medium of embodiment 716, further, comprising:-   the processor-executable instructions structured as:    -   transpose, via at least one processor, the calculated expected        returns for the set of asset database table records in the        assets batch database table into a wide array format; and    -   write, via at least one processor, via a parallel SQL query, the        transposed expected returns to an asset simulation wide table.-   726. The medium of embodiment 725, further, comprising:-   the asset simulation wide table formatted to facilitate efficient    calculation of portfolio return metrics; and-   the asset simulation wide table structured to be written to in    parallel by query server processes from a plurality of utilized    sessions.-   727. The medium of embodiment 716, further, comprising:-   the processor-executable instructions structured as:    -   calculate, via at least one processor, via a parallel SQL query,        an asset return metric based on the calculated expected returns        for the set of asset database table records in the assets batch        database table;    -   transpose, via at least one processor, the calculated asset        return metric for the set of asset database table records in the        assets batch database table into a wide array format; and    -   write, via at least one processor, via a parallel SQL query, the        transposed asset return metric to an asset simulation wide        table.-   728. The medium of embodiment 716, further, comprising:-   the processor-executable instructions structured as:    -   write, via at least one processor, via a parallel SQL query, the        calculated expected returns to an asset measure table.-   729. The medium of embodiment 716, further, comprising:-   the processor-executable instructions structured as:    -   calculate, via at least one processor, via a parallel SQL query,        an asset return metric based on the calculated expected returns        for the set of asset database table records in the assets batch        database table; and    -   write, via at least one processor, via a parallel SQL query, the        calculated asset return metric to an asset measure table.-   730. The medium of embodiment 729, further, comprising:-   the asset measure table formatted to facilitate efficient    calculation of security return metrics; and-   the asset measure table structured to be written to in parallel by    query server processes from a plurality of utilized sessions.-   731. A database calculation engine processor-implemented system,    comprising:-   means to process processor-executable instructions;-   means to issue processor-issuable instructions from a    processor-executable component collection via the means to process    processor-executable instructions, the processor-issuable    instructions structured as:    -   obtain, via at least one processor, an asset return metrics        calculation request datastructure, the asset return metrics        calculation request datastructure structured to specify a set of        assets and a set of simulated market scenarios, each simulated        market scenario in the set of simulated market scenarios        structured to comprise a set of simulated market factor values        corresponding to a set of market factors;    -   determine, via at least one processor, a number of sessions to        utilize for calculating asset return metrics data;    -   determine, via at least one processor, an assets range for a        session based on the determined number of sessions to utilize,        the assets range comprising a set of asset database table        records for the set of assets to be processed by the session;    -   create, via at least one processor, an assets batch database        table, the assets batch database table structured to comprise a        set of asset database table records of a specified batch size        from the assets range for the session;    -   create, via at least one processor, a factor simulations batch        database table, the factor simulations batch database table        structured to comprise a set of simulated market factor return        values for the set of asset database table records in the assets        batch database table;    -   create, via at least one processor, a factor exposures batch        database table, the factor exposures batch database table        structured to comprise a set of factor exposure database table        records matching the set of asset database table records in the        assets batch database table; and    -   calculate, via at least one processor, via a parallel SQL query,        expected returns for the set of asset database table records in        the assets batch database table, using the factor simulations        batch database table and the factor exposures batch database        table.-   732. The system of embodiment 731, further, comprising:-   the set of simulated market factor values for a simulated market    scenario is configured as generated using a set of deep learning    neural networks.-   733. The system of embodiment 731, further, comprising:-   the set of simulated market factor values for a simulated market    scenario is configured as generated using a set of multi-variate    mixture datastructures.-   734. The system of embodiment 731, further, comprising:-   the processor-executable instructions structured as:    -   filter, via at least one processor, asset database table records        associated with the set of assets, based on available factor        exposure database table records, using a SQL statement.-   735. The system of embodiment 734, further, comprising:-   the processor-executable instructions structured as:    -   filter, via at least one processor, simulated market scenario        database table records associated with the set of simulated        market scenarios, based on a subset of market factors from the        set of market factors to which the filtered asset database table        records have exposure, using a SQL statement.-   736. The system of embodiment 731, further, comprising:-   the number of sessions to utilize for calculating asset return    metrics data is determined based on the number of available server    processors and a specified degree of parallelism per session.-   737. The system of embodiment 731, further, comprising:-   the assets batch database table, the factor simulations batch    database table, and the factor exposures batch database table are    temporary database tables.-   738. The system of embodiment 734, further, comprising:-   the processor-executable instructions structured as:    -   filter, via at least one processor, at least one of call        schedule database table records and put schedule database table        records based on the filtered asset database table records.-   739. The system of embodiment 738, further, comprising:-   the processor-executable instructions structured as:    -   adjust, via at least one processor, via a parallel SQL query,        the calculated expected returns for the set of asset database        table records in the assets batch database table, based on at        least one of the filtered call schedule database table records        and the filtered put schedule database table records.-   740. The system of embodiment 731, further, comprising:-   the processor-executable instructions structured as:    -   transpose, via at least one processor, the calculated expected        returns for the set of asset database table records in the        assets batch database table into a wide array format; and    -   write, via at least one processor, via a parallel SQL query, the        transposed expected returns to an asset simulation wide table.-   741. The system of embodiment 740, further, comprising:-   the asset simulation wide table formatted to facilitate efficient    calculation of portfolio return metrics; and-   the asset simulation wide table structured to be written to in    parallel by query server processes from a plurality of utilized    sessions.-   742. The system of embodiment 731, further, comprising:-   the processor-executable instructions structured as:    -   calculate, via at least one processor, via a parallel SQL query,        an asset return metric based on the calculated expected returns        for the set of asset database table records in the assets batch        database table;    -   transpose, via at least one processor, the calculated asset        return metric for the set of asset database table records in the        assets batch database table into a wide array format; and    -   write, via at least one processor, via a parallel SQL query, the        transposed asset return metric to an asset simulation wide        table.-   743. The system of embodiment 731, further, comprising:-   the processor-executable instructions structured as:    -   write, via at least one processor, via a parallel SQL query, the        calculated expected returns to an asset measure table.-   744. The system of embodiment 731, further, comprising:-   the processor-executable instructions structured as:    -   calculate, via at least one processor, via a parallel SQL query,        an asset return metric based on the calculated expected returns        for the set of asset database table records in the assets batch        database table; and    -   write, via at least one processor, via a parallel SQL query, the        calculated asset return metric to an asset measure table.-   745. The system of embodiment 744, further, comprising:-   the asset measure table formatted to facilitate efficient    calculation of security return metrics; and-   the asset measure table structured to be written to in parallel by    query server processes from a plurality of utilized sessions.-   746. A database calculation engine processor-implemented process,    comprising executing processor-executable instructions to:    -   obtain, via at least one processor, an asset return metrics        calculation request datastructure, the asset return metrics        calculation request datastructure structured to specify a set of        assets and a set of simulated market scenarios, each simulated        market scenario in the set of simulated market scenarios        structured to comprise a set of simulated market factor values        corresponding to a set of market factors;    -   determine, via at least one processor, a number of sessions to        utilize for calculating asset return metrics data;    -   determine, via at least one processor, an assets range for a        session based on the determined number of sessions to utilize,        the assets range comprising a set of asset database table        records for the set of assets to be processed by the session;    -   create, via at least one processor, an assets batch database        table, the assets batch database table structured to comprise a        set of asset database table records of a specified batch size        from the assets range for the session;    -   create, via at least one processor, a factor simulations batch        database table, the factor simulations batch database table        structured to comprise a set of simulated market factor return        values for the set of asset database table records in the assets        batch database table;    -   create, via at least one processor, a factor exposures batch        database table, the factor exposures batch database table        structured to comprise a set of factor exposure database table        records matching the set of asset database table records in the        assets batch database table; and    -   calculate, via at least one processor, via a parallel SQL query,        expected returns for the set of asset database table records in        the assets batch database table, using the factor simulations        batch database table and the factor exposures batch database        table.-   747. The process of embodiment 746, further, comprising:-   the set of simulated market factor values for a simulated market    scenario is configured as generated using a set of deep learning    neural networks.-   748. The process of embodiment 746, further, comprising:-   the set of simulated market factor values for a simulated market    scenario is configured as generated using a set of multi-variate    mixture datastructures.-   749. The process of embodiment 746, further, comprising:-   the processor-executable instructions structured as:    -   filter, via at least one processor, asset database table records        associated with the set of assets, based on available factor        exposure database table records, using a SQL statement.-   750. The process of embodiment 749, further, comprising:-   the processor-executable instructions structured as:    -   filter, via at least one processor, simulated market scenario        database table records associated with the set of simulated        market scenarios, based on a subset of market factors from the        set of market factors to which the filtered asset database table        records have exposure, using a SQL statement.-   751. The process of embodiment 746, further, comprising:-   the number of sessions to utilize for calculating asset return    metrics data is determined based on the number of available server    processors and a specified degree of parallelism per session.-   752. The process of embodiment 746, further, comprising:-   the assets batch database table, the factor simulations batch    database table, and the factor exposures batch database table are    temporary database tables.-   753. The process of embodiment 749, further, comprising:-   the processor-executable instructions structured as:    -   filter, via at least one processor, at least one of call        schedule database table records and put schedule database table        records based on the filtered asset database table records.-   754. The process of embodiment 753, further, comprising:-   the processor-executable instructions structured as:    -   adjust, via at least one processor, via a parallel SQL query,        the calculated expected returns for the set of asset database        table records in the assets batch database table, based on at        least one of the filtered call schedule database table records        and the filtered put schedule database table records.-   755. The process of embodiment 746, further, comprising:-   the processor-executable instructions structured as:    -   transpose, via at least one processor, the calculated expected        returns for the set of asset database table records in the        assets batch database table into a wide array format; and    -   write, via at least one processor, via a parallel SQL query, the        transposed expected returns to an asset simulation wide table.-   756. The process of embodiment 755, further, comprising:-   the asset simulation wide table formatted to facilitate efficient    calculation of portfolio return metrics; and-   the asset simulation wide table structured to be written to in    parallel by query server processes from a plurality of utilized    sessions.-   757. The process of embodiment 746, further, comprising:-   the processor-executable instructions structured as:    -   calculate, via at least one processor, via a parallel SQL query,        an asset return metric based on the calculated expected returns        for the set of asset database table records in the assets batch        database table;    -   transpose, via at least one processor, the calculated asset        return metric for the set of asset database table records in the        assets batch database table into a wide array format; and    -   write, via at least one processor, via a parallel SQL query, the        transposed asset return metric to an asset simulation wide        table.-   758. The process of embodiment 746, further, comprising:-   the processor-executable instructions structured as:    -   write, via at least one processor, via a parallel SQL query, the        calculated expected returns to an asset measure table.-   759. The process of embodiment 746, further, comprising:-   the processor-executable instructions structured as:    -   calculate, via at least one processor, via a parallel SQL query,        an asset return metric based on the calculated expected returns        for the set of asset database table records in the assets batch        database table; and    -   write, via at least one processor, via a parallel SQL query, the        calculated asset return metric to an asset measure table.-   760. The process of embodiment 759, further, comprising:-   the asset measure table formatted to facilitate efficient    calculation of security return metrics; and-   the asset measure table structured to be written to in parallel by    query server processes from a plurality of utilized sessions.

MLPO Controller

FIG. 99 shows a block diagram illustrating embodiments of a MLPOcontroller. In this embodiment, the MLPO controller 9901 may serve toaggregate, process, store, search, serve, identify, instruct, generate,match, and/or facilitate interactions with a computer through machinelearning and database systems technologies, and/or other related data.

Users, which may be people and/or other systems, may engage informationtechnology systems (e.g., computers) to facilitate informationprocessing. In turn, computers employ processors to process information;such processors 9903 may be referred to as central processing units(CPU). One form of processor is referred to as a microprocessor. CPUsuse communicative circuits to pass binary encoded signals acting asinstructions to allow various operations. These instructions may beoperational and/or data instructions containing and/or referencing otherinstructions and data in various processor accessible and operable areasof memory 9929 (e.g., registers, cache memory, random access memory,etc.). Such communicative instructions may be stored and/or transmittedin batches (e.g., batches of instructions) as programs and/or datacomponents to facilitate desired operations. These stored instructioncodes, e.g., programs, may engage the CPU circuit components and othermotherboard and/or system components to perform desired operations. Onetype of program is a computer operating system, which, may be executedby CPU on a computer; the operating system enables and facilitates usersto access and operate computer information technology and resources.Some resources that may be employed in information technology systemsinclude: input and output mechanisms through which data may pass intoand out of a computer; memory storage into which data may be saved; andprocessors by which information may be processed. These informationtechnology systems may be used to collect data for later retrieval,analysis, and manipulation, which may be facilitated through a databaseprogram. These information technology systems provide interfaces thatallow users to access and operate various system components.

In one embodiment, the MLPO controller 9901 may be connected to and/orcommunicate with entities such as, but not limited to: one or more usersfrom peripheral devices 9912 (e.g., user input devices 9911); anoptional cryptographic processor device 9928; and/or a communicationsnetwork 9913.

Networks comprise the interconnection and interoperation of clients,servers, and intermediary nodes in a graph topology. It should be notedthat the term “server” as used throughout this application refersgenerally to a computer, other device, program, or combination thereofthat processes and responds to the requests of remote users across acommunications network. Servers serve their information to requesting“clients.” The term “client” as used herein refers generally to acomputer, program, other device, user and/or combination thereof that iscapable of processing and making requests and obtaining and processingany responses from servers across a communications network. A computer,other device, program, or combination thereof that facilitates,processes information and requests, and/or furthers the passage ofinformation from a source user to a destination user is referred to as a“node.” Networks are generally thought to facilitate the transfer ofinformation from source points to destinations. A node specificallytasked with furthering the passage of information from a source to adestination is called a “router.” There are many forms of networks suchas Local Area Networks (LANs), Pico networks, Wide Area Networks (WANs),Wireless Networks (WLANs), etc. For example, the Internet is, generally,an interconnection of a multitude of networks whereby remote clients andservers may access and interoperate with one another.

The MLPO controller 9901 may be based on computer systems that maycomprise, but are not limited to, components such as: a computersystemization 9902 connected to memory 9929.

Computer Systemization

A computer systemization 9902 may comprise a clock 9930, centralprocessing unit (“CPU(s)” and/or “processor(s)” (these terms are usedinterchangeable throughout the disclosure unless noted to the contrary))9903, a memory 9929 (e.g., a read only memory (ROM) 9906, a randomaccess memory (RAM) 9905, etc.), and/or an interface bus 9907, and mostfrequently, although not necessarily, are all interconnected and/orcommunicating through a system bus 9904 on one or more (mother)board(s)9902 having conductive and/or otherwise transportive circuit pathwaysthrough which instructions (e.g., binary encoded signals) may travel toeffectuate communications, operations, storage, etc. The computersystemization may be connected to a power source 9986; e.g., optionallythe power source may be internal. Optionally, a cryptographic processor9926 may be connected to the system bus. In another embodiment, thecryptographic processor, transceivers (e.g., ICs) 9974, and/or sensorarray (e.g., accelerometer, altimeter, ambient light, barometer, globalpositioning system (GPS) (thereby allowing MLPO controller to determineits location), gyroscope, magnetometer, pedometer, proximity,ultra-violet sensor, etc.) 9973 may be connected as either internaland/or external peripheral devices 9912 via the interface bus I/O 9908(not pictured) and/or directly via the interface bus 9907. In turn, thetransceivers may be connected to antenna(s) 9975, thereby effectuatingwireless transmission and reception of various communication and/orsensor protocols; for example the antenna(s) may connect to varioustransceiver chipsets (depending on deployment needs), including:Broadcom® BCM4329FKUBG transceiver chip (e.g., providing 802.11n,Bluetooth 2.1+EDR, FM, etc.); a Broadcom® BCM4752 GPS receiver withaccelerometer, altimeter, GPS, gyroscope, magnetometer; a Broadcom®BCM4335 transceiver chip (e.g., providing 2G, 3G, and 4G long-termevolution (LTE) cellular communications; 802.11ac, Bluetooth 4.0 lowenergy (LE) (e.g., beacon features)); a Broadcom® BCM43341 transceiverchip (e.g., providing 2G, 3G and 4G LTE cellular communications; 802.11g/, Bluetooth 4.0, near field communication (NFC), FM radio); anInfineon Technologies® X-Gold 618-PMB9800 transceiver chip (e.g.,providing 2G/3G HSDPA/HSUPA communications); a MediaTek® MT6620transceiver chip (e.g., providing 802.11a/ac/b/g/n, Bluetooth 4.0 LE,FM, GPS; a Lapis Semiconductor® ML8511 UV sensor; a maxim integratedMAX44000 ambient light and infrared proximity sensor; a TexasInstruments® WiLink WL1283 transceiver chip (e.g., providing 802.11n,Bluetooth 3.0, FM, GPS); and/or the like. The system clock may have acrystal oscillator and generates a base signal through the computersystemization's circuit pathways. The clock may be coupled to the systembus and various clock multipliers that will increase or decrease thebase operating frequency for other components interconnected in thecomputer systemization. The clock and various components in a computersystemization drive signals embodying information throughout the system.Such transmission and reception of instructions embodying informationthroughout a computer systemization may be referred to ascommunications. These communicative instructions may further betransmitted, received, and the cause of return and/or replycommunications beyond the instant computer systemization to:communications networks, input devices, other computer systemizations,peripheral devices, and/or the like. It should be understood that inalternative embodiments, any of the above components may be connecteddirectly to one another, connected to the CPU, and/or organized innumerous variations employed as exemplified by various computer systems.

The CPU comprises at least one high-speed data processor adequate toexecute program components for executing user and/or system-generatedrequests. The CPU is often packaged in a number of formats varying fromlarge supercomputer(s) and mainframe(s) computers, down to minicomputers, servers, desktop computers, laptops, thin clients (e.g.,Chromebooks®), netbooks, tablets (e.g., Android®, iPads®, and Windows®tablets, etc.), mobile smartphones (e.g., Android®, iPhones®, Nokia®,Palm® and Windows® phones, etc.), wearable device(s) (e.g., watches,glasses, goggles (e.g., Google Glass), etc.), and/or the like. Often,the processors themselves will incorporate various specializedprocessing units, such as, but not limited to: integrated system (bus)controllers, memory management control units, floating point units, andeven specialized processing sub-units like graphics processing units,digital signal processing units, and/or the like. Additionally,processors may include internal fast access addressable memory, and becapable of mapping and addressing memory 9929 beyond the processoritself; internal memory may include, but is not limited to: fastregisters, various levels of cache memory (e.g., level 1, 2, 3, etc.),RAM, etc. The processor may access this memory through the use of amemory address space that is accessible via instruction address, whichthe processor can construct and decode allowing it to access a circuitpath to a specific memory address space having a memory state. The CPUmay be a microprocessor such as: AMD's Athlon®, Duron® and/or Opteron®;Apple's® A series of processors (e.g., A5, A6, A7, A8, etc.); ARM's®application, embedded and secure processors; IBM® and/or Motorola'sDragonBall® and PowerPC®; IBM's® and Sony's® Cell processor; Intel's®80X86 series (e.g., 80386, 80486), Pentium®, Celeron®, Core (2) Duo®, iseries (e.g., i3, i5, i7, etc.), Itanium®, Xeon®, and/or XScale®;Motorola's® 680X0 series (e.g., 68020, 68030, 68040, etc.); and/or thelike processor(s). The CPU interacts with memory through instructionpassing through conductive and/or transportive conduits (e.g., (printed)electronic and/or optic circuits) to execute stored instructions (i.e.,program code) according to various data processing techniques. Suchinstruction passing facilitates communication within the MLPO controllerand beyond through various interfaces. Should processing requirementsdictate a greater amount speed and/or capacity, distributed processors(e.g., see Distributed MLPO below), mainframe, multi-core, parallel,and/or super-computer architectures may similarly be employed.Alternatively, should deployment requirements dictate greaterportability, smaller mobile devices (e.g., Personal Digital Assistants(PDAs)) may be employed.

Depending on the particular implementation, features of the MLPO may beachieved by implementing a microcontroller such as CAST's® R8051XC2microcontroller; Intel's® MCS 51 (i.e., 8051 microcontroller); and/orthe like. Also, to implement certain features of the MLPO, some featureimplementations may rely on embedded components, such as:Application-Specific Integrated Circuit (“ASIC”), Digital SignalProcessing (“DSP”), Field Programmable Gate Array (“FPGA”), and/or thelike embedded technology. For example, any of the MLPO componentcollection (distributed or otherwise) and/or features may be implementedvia the microprocessor and/or via embedded components; e.g., via ASIC,coprocessor, DSP, FPGA, and/or the like. Alternately, someimplementations of the MLPO may be implemented with embedded componentsthat are configured and used to achieve a variety of features or signalprocessing.

Depending on the particular implementation, the embedded components mayinclude software solutions, hardware solutions, and/or some combinationof both hardware/software solutions. For example, MLPO featuresdiscussed herein may be achieved through implementing FPGAs, which are asemiconductor devices containing programmable logic components called“logic blocks”, and programmable interconnects, such as the highperformance FPGA Virtex® series and/or the low cost Spartan® seriesmanufactured by Xilinx®. Logic blocks and interconnects can beprogrammed by the customer or designer, after the FPGA is manufactured,to implement any of the MLPO features. A hierarchy of programmableinterconnects allow logic blocks to be interconnected as needed by theMLPO system designer/administrator, somewhat like a one-chipprogrammable breadboard. An FPGA's logic blocks can be programmed toperform the operation of basic logic gates such as AND, and XOR, or morecomplex combinational operators such as decoders or mathematicaloperations. In most FPGAs, the logic blocks also include memoryelements, which may be circuit flip-flops or more complete blocks ofmemory. In some circumstances, the MLPO may be developed on FPGAs andthen migrated into a fixed version that more resembles ASICimplementations. Alternate or coordinating implementations may migrateMLPO controller features to a final ASIC instead of or in addition toFPGAs. Depending on the implementation all of the aforementionedembedded components and microprocessors may be considered the “CPU”and/or “processor” for the MLPO.

Power Source

The power source 9986 may be of any various form for powering smallelectronic circuit board devices such as the following power cells:alkaline, lithium hydride, lithium ion, lithium polymer, nickel cadmium,solar cells, and/or the like. Other types of AC or DC power sources maybe used as well. In the case of solar cells, in one embodiment, the caseprovides an aperture through which the solar cell may capture photonicenergy. The power cell 9986 is connected to at least one of theinterconnected subsequent components of the MLPO thereby providing anelectric current to all subsequent components. In one example, the powersource 9986 is connected to the system bus component 9904. In analternative embodiment, an outside power source 9986 is provided througha connection across the I/O 9908 interface. For example, a USB and/orIEEE 1394 connection carries both data and power across the connectionand is therefore a suitable source of power.

Interface Adapters

Interface bus(ses) 9907 may accept, connect, and/or communicate to anumber of interface adapters, variously although not necessarily in theform of adapter cards, such as but not limited to: input outputinterfaces (I/O) 9908, storage interfaces 9909, network interfaces 9910,and/or the like. Optionally, cryptographic processor interfaces 9927similarly may be connected to the interface bus. The interface busprovides for the communications of interface adapters with one anotheras well as with other components of the computer systemization.Interface adapters are adapted for a compatible interface bus. Interfaceadapters variously connect to the interface bus via a slot architecture.Various slot architectures may be employed, such as, but not limited to:Accelerated Graphics Port (AGP), Card Bus, (Extended) Industry StandardArchitecture ((E)ISA), Micro Channel Architecture (MCA), NuBus,Peripheral Component Interconnect (Extended) (PCI(X)), PCI Express,Personal Computer Memory Card International Association (PCMCIA), and/orthe like.

Storage interfaces 9909 may accept, communicate, and/or connect to anumber of storage devices such as, but not limited to: storage devices9914, removable disc devices, and/or the like. Storage interfaces mayemploy connection protocols such as, but not limited to: (Ultra)(Serial) Advanced Technology Attachment (Packet Interface) ((Ultra)(Serial) ATA(PI)), (Enhanced) Integrated Drive Electronics ((E)IDE),Institute of Electrical and Electronics Engineers (IEEE) 1394, fiberchannel, Small Computer Systems Interface (SCSI), Universal Serial Bus(USB), and/or the like.

Network interfaces 9910 may accept, communicate, and/or connect to acommunications network 9913. Through a communications network 9913, theMLPO controller is accessible through remote clients 9933 b (e.g.,computers with web browsers) by users 9933 a. Network interfaces mayemploy connection protocols such as, but not limited to: direct connect,Ethernet (thick, thin, twisted pair 10/100/1000/10000 Base T, and/or thelike), Token Ring, wireless connection such as IEEE 802.11a-x, and/orthe like. Should processing requirements dictate a greater amount speedand/or capacity, distributed network controllers (e.g., see DistributedMLPO below), architectures may similarly be employed to pool, loadbalance, and/or otherwise decrease/increase the communicative bandwidthrequired by the MLPO controller. A communications network may be any oneand/or the combination of the following: a direct interconnection; theInternet; Interplanetary Internet (e.g., Coherent File DistributionProtocol (CFDP), Space Communications Protocol Specifications (SCPS),etc.); a Local Area Network (LAN); a Metropolitan Area Network (MAN); anOperating Missions as Nodes on the Internet (OMNI); a secured customconnection; a Wide Area Network (WAN); a wireless network (e.g.,employing protocols such as, but not limited to a cellular, WiFi,Wireless Application Protocol (WAP), I-mode, and/or the like); and/orthe like. A network interface may be regarded as a specialized form ofan input output interface. Further, multiple network interfaces 9910 maybe used to engage with various communications network types 9913. Forexample, multiple network interfaces may be employed to allow for thecommunication over broadcast, multicast, and/or unicast networks.

Input Output interfaces (I/O) 9908 may accept, communicate, and/orconnect to user, peripheral devices 9912 (e.g., input devices 9911),cryptographic processor devices 9928, and/or the like. I/O may employconnection protocols such as, but not limited to: audio: analog,digital, monaural, RCA, stereo, and/or the like; data: Apple Desktop Bus(ADB), IEEE 1394a-b, serial, universal serial bus (USB); infrared;joystick; keyboard; midi; optical; PC AT; PS/2; parallel; radio; touchinterfaces: capacitive, optical, resistive, etc. displays; videointerface: Apple Desktop Connector (ADC), BNC, coaxial, component,composite, digital, Digital Visual Interface (DVI), (mini) displayport,high-definition multimedia interface (HDMI), RCA, RF antennae, S-Video,VGA, and/or the like; wireless transceivers: 802.11a/ac/b/g/n/x;Bluetooth; cellular (e.g., code division multiple access (CDMA), highspeed packet access (HSPA(+)), high-speed downlink packet access(HSDPA), global system for mobile communications (GSM), long termevolution (LTE), WiMax, etc.); and/or the like. One output device mayinclude a video display, which may comprise a Cathode Ray Tube (CRT) orLiquid Crystal Display (LCD) based monitor with an interface (e.g., DVIcircuitry and cable) that accepts signals from a video interface, may beused. The video interface composites information generated by a computersystemization and generates video signals based on the compositedinformation in a video memory frame. Another output device is atelevision set, which accepts signals from a video interface. The videointerface provides the composited video information through a videoconnection interface that accepts a video display interface (e.g., anRCA composite video connector accepting an RCA composite video cable; aDVI connector accepting a DVI display cable, etc.).

Peripheral devices 9912 may be connected and/or communicate to I/Oand/or other facilities of the like such as network interfaces, storageinterfaces, directly to the interface bus, system bus, the CPU, and/orthe like. Peripheral devices may be external, internal and/or part ofthe MLPO controller. Peripheral devices may include: antenna, audiodevices (e.g., line-in, line-out, microphone input, speakers, etc.),cameras (e.g., gesture (e.g., Microsoft Kinect) detection, motiondetection, still, video, webcam, etc.), dongles (e.g., for copyprotection, ensuring secure transactions with a digital signature,and/or the like), external processors (for added capabilities; e.g.,crypto devices 528), force-feedback devices (e.g., vibrating motors),infrared (IR) transceiver, network interfaces, printers, scanners,sensors/sensor arrays and peripheral extensions (e.g., ambient light,GPS, gyroscopes, proximity, temperature, etc.), storage devices,transceivers (e.g., cellular, GPS, etc.), video devices (e.g., goggles,monitors, etc.), video sources, visors, and/or the like. Peripheraldevices often include types of input devices (e.g., cameras).

User input devices 9911 often are a type of peripheral device 512 (seeabove) and may include: card readers, dongles, finger print readers,gloves, graphics tablets, joysticks, keyboards, microphones, mouse(mice), remote controls, security/biometric devices (e.g., fingerprintreader, iris reader, retina reader, etc.), touch screens (e.g.,capacitive, resistive, etc.), trackballs, trackpads, styluses, and/orthe like.

It should be noted that although user input devices and peripheraldevices may be employed, the MLPO controller may be embodied as anembedded, dedicated, and/or monitor-less (i.e., headless) device,wherein access would be provided over a network interface connection.

Cryptographic units such as, but not limited to, microcontrollers,processors 9926, interfaces 9927, and/or devices 9928 may be attached,and/or communicate with the MLPO controller. A MC68HC16 microcontroller,manufactured by Motorola, Inc.®, may be used for and/or withincryptographic units. The MC68HC16 microcontroller utilizes a 16-bitmultiply-and-accumulate instruction in the 16 MHz configuration andrequires less than one second to perform a 512-bit RSA private keyoperation. Cryptographic units support the authentication ofcommunications from interacting agents, as well as allowing foranonymous transactions. Cryptographic units may also be configured aspart of the CPU. Equivalent microcontrollers and/or processors may alsobe used. Other specialized cryptographic processors include: Broadcom's®CryptoNetX and other Security Processors; nCipher's® nShield; SafeNet's®Luna PCI (e.g., 7100) series; Semaphore Communications'® 40 MHzRoadrunner 184; Sun's® Cryptographic Accelerators (e.g., Accelerator6000 PCIe Board, Accelerator 500 Daughtercard); Via Nano® Processor(e.g., L2100, L2200, U2400) line, which is capable of performing500+MB/s of cryptographic instructions; VLSI Technology's® 33 MHz 6868;and/or the like.

Memory

Generally, any mechanization and/or embodiment allowing a processor toaffect the storage and/or retrieval of information is regarded as memory9929. However, memory is a fungible technology and resource, thus, anynumber of memory embodiments may be employed in lieu of or in concertwith one another. It is to be understood that the MLPO controller and/ora computer systemization may employ various forms of memory 9929. Forexample, a computer systemization may be configured wherein theoperation of on-chip CPU memory (e.g., registers), RAM, ROM, and anyother storage devices are provided by a paper punch tape or paper punchcard mechanism; however, such an embodiment would result in an extremelyslow rate of operation. In one configuration, memory 9929 will includeROM 9906, RAM 9905, and a storage device 9914. A storage device 9914 maybe any various computer system storage. Storage devices may include: anarray of devices (e.g., Redundant Array of Independent Disks (RAID)); adrum; a (fixed and/or removable) magnetic disk drive; a magneto-opticaldrive; an optical drive (i.e., Blueray, CD ROM/RAM/Recordable(R)/ReWritable (RW), DVD R/RW, HD DVD R/RW etc.); RAM drives; solidstate memory devices (USB memory, solid state drives (SSD), etc.); otherprocessor-readable storage mediums; and/or other devices of the like.Thus, a computer systemization generally requires and makes use ofmemory.

Component Collection

The memory 9929 may contain a collection of program and/or databasecomponents and/or data such as, but not limited to: operating systemcomponent(s) 9915 (operating system); information server component(s)9916 (information server); user interface component(s) 9917 (userinterface); Web browser component(s) 9918 (Web browser); database(s)9919; mail server component(s) 9921; mail client component(s) 9922;cryptographic server component(s) 9920 (cryptographic server); the MLPOcomponent(s) 9935; and/or the like (i.e., collectively a componentcollection). These components may be stored and accessed from thestorage devices and/or from storage devices accessible through aninterface bus. Although unconventional program components such as thosein the component collection may be stored in a local storage device9914, they may also be loaded and/or stored in memory such as:peripheral devices, RAM, remote storage facilities through acommunications network, ROM, various forms of memory, and/or the like.

Operating System

The operating system component 9915 is an executable program componentfacilitating the operation of the MLPO controller. The operating systemmay facilitate access of I/O, network interfaces, peripheral devices,storage devices, and/or the like. The operating system may be a highlyfault tolerant, scalable, and secure system such as: Apple's MacintoshOS X (Server) and macOS®; AT&T Plan 9®; Be OS®; Blackberry's QNX®;Google's Chrome®; Microsoft's Windows® 7/8/10; Unix and Unix-like systemdistributions (such as AT&T's UNIX®; Berkley Software Distribution(BSD)® variations such as FreeBSD®, NetBSD, OpenBSD, and/or the like;Linux distributions such as Red Hat, Ubuntu, and/or the like); and/orthe like operating systems. However, more limited and/or less secureoperating systems also may be employed such as Apple Macintosh OS®(i.e., versions 1-9), IBM OS/2®, Microsoft DOS®, Microsoft Windows2000/2003/3.1/95/98/CE/Millenium/Mobile/NT/Vista/XP (Server)®, Palm OS®,and/or the like. Additionally, for robust mobile deploymentapplications, mobile operating systems may be used, such as: Apple'siOS®; China Operating System COS®; Google's Android®; Microsoft WindowsRT/Phone®; Palm's WebOS®; Samsung/Intel's Tizen®; and/or the like. Anoperating system may communicate to and/or with other components in acomponent collection, including itself, and/or the like. Mostfrequently, the operating system communicates with other programcomponents, user interfaces, and/or the like. For example, the operatingsystem may contain, communicate, generate, obtain, and/or provideprogram component, system, user, and/or data communications, requests,and/or responses. The operating system, once executed by the CPU, mayenable the interaction with communications networks, data, I/O,peripheral devices, program components, memory, user input devices,and/or the like. The operating system may provide communicationsprotocols that allow the MLPO controller to communicate with otherentities through a communications network 9913. Various communicationprotocols may be used by the MLPO controller as a subcarrier transportmechanism for interaction, such as, but not limited to: multicast,TCP/IP, UDP, unicast, and/or the like.

Information Server

An information server component 9916 is a stored program component thatis executed by a CPU. The information server may be an Internetinformation server such as, but not limited to Apache SoftwareFoundation's Apache, Microsoft's Internet Information Server, and/or thelike. The information server may allow for the execution of programcomponents through facilities such as Active Server Page (ASP), ActiveX,(ANSI) (Objective-) C (++), C # and/or .NET, Common Gateway Interface(CGI) scripts, dynamic (D) hypertext markup language (HTML), FLASH,Java, JavaScript, Practical Extraction Report Language (PERL), HypertextPre-Processor (PHP), pipes, Python, wireless application protocol (WAP),WebObjects®, and/or the like. The information server may support securecommunications protocols such as, but not limited to, File TransferProtocol (FTP); HyperText Transfer Protocol (HTTP); Secure HypertextTransfer Protocol (HTTPS), Secure Socket Layer (SSL), messagingprotocols (e.g., America Online (AOL) Instant Messenger (AIM)®,Application Exchange (APEX), ICQ, Internet Relay Chat (IRC), MicrosoftNetwork (MSN) Messenger® Service, Presence and Instant MessagingProtocol (PRIM), Internet Engineering Task Force's® (IETF's) SessionInitiation Protocol (SIP), SIP for Instant Messaging and PresenceLeveraging Extensions (SIMPLE), open XML-based Extensible Messaging andPresence Protocol (XMPP) (i.e., Jabber® or Open Mobile Alliance's(OMA's) Instant Messaging and Presence Service (IMPS)), Yahoo! InstantMessenger® Service, and/or the like. The information server providesresults in the form of Web pages to Web browsers, and allows for themanipulated generation of the Web pages through interaction with otherprogram components. After a Domain Name System (DNS) resolution portionof an HTTP request is resolved to a particular information server, theinformation server resolves requests for information at specifiedlocations on the MLPO controller based on the remainder of the HTTPrequest. For example, a request such ashttp://123.124.125.126/myInformation.html might have the IP portion ofthe request “123.124.125.126” resolved by a DNS server to an informationserver at that IP address; that information server might in turn furtherparse the http request for the “/myInformation.html” portion of therequest and resolve it to a location in memory containing theinformation “myInformation.html.” Additionally, other informationserving protocols may be employed across various ports, e.g., FTPcommunications across port 21, and/or the like. An information servermay communicate to and/or with other components in a componentcollection, including itself, and/or facilities of the like. Mostfrequently, the information server communicates with the MLPO database9919, operating systems, other program components, user interfaces, Webbrowsers, and/or the like.

Access to the MLPO database may be achieved through a number of databasebridge mechanisms such as through scripting languages as enumeratedbelow (e.g., CGI) and through inter-application communication channelsas enumerated below (e.g., CORBA, WebObjects, etc.). Any data requeststhrough a Web browser are parsed through the bridge mechanism intoappropriate grammars as required by the MLPO. In one embodiment, theinformation server would provide a Web form accessible by a Web browser.Entries made into supplied fields in the Web form are tagged as havingbeen entered into the particular fields, and parsed as such. The enteredterms are then passed along with the field tags, which act to instructthe parser to generate queries directed to appropriate tables and/orfields. In one embodiment, the parser may generate queries in SQL byinstantiating a search string with the proper join/select commands basedon the tagged text entries, wherein the resulting command is providedover the bridge mechanism to the MLPO as a query. Upon generating queryresults from the query, the results are passed over the bridgemechanism, and may be parsed for formatting and generation of a newresults Web page by the bridge mechanism. Such a new results Web page isthen provided to the information server, which may supply it to therequesting Web browser.

Also, an information server may contain, communicate, generate, obtain,and/or provide program component, system, user, and/or datacommunications, requests, and/or responses.

User Interface

Computer interfaces in some respects are similar to automobile operationinterfaces. Automobile operation interface elements such as steeringwheels, gearshifts, and speedometers facilitate the access, operation,and display of automobile resources, and status. Computer interactioninterface elements such as buttons, check boxes, cursors, menus,scrollers, and windows (collectively referred to as widgets) similarlyfacilitate the access, capabilities, operation, and display of data andcomputer hardware and operating system resources, and status. Operationinterfaces are called user interfaces. Graphical user interfaces (GUIs)such as the Apple's iOS®, Macintosh Operating System's Aqua®; IBM'sOS/2®; Google's Chrome® (e.g., and other webbrowser/cloud based clientOSs); Microsoft's Windows® varied UIs2000/2003/3.1/95/98/CE/Millenium/Mobile/NT/Vista/XP (Server) (i.e.,Aero, Surface, etc.); Unix's X-Windows (e.g., which may includeadditional Unix graphic interface libraries and layers such as K DesktopEnvironment (KDE), mythTV and GNU Network Object Model Environment(GNOME)), web interface libraries (e.g., ActiveX, AJAX, (D)HTML, FLASH,Java, JavaScript, etc. interface libraries such as, but not limited to,Dojo, jQuery(UI), MooTools, Prototype, script.aculo.us, SWFObject,Yahoo! User Interface®, any of which may be used and) provide a baselineand means of accessing and displaying information graphically to users.

A user interface component 9917 is a stored program component that isexecuted by a CPU. The user interface may be a graphic user interface asprovided by, with, and/or atop operating systems and/or operatingenvironments such as already discussed. The user interface may allow forthe display, execution, interaction, manipulation, and/or operation ofprogram components and/or system facilities through textual and/orgraphical facilities. The user interface provides a facility throughwhich users may affect, interact, and/or operate a computer system. Auser interface may communicate to and/or with other components in acomponent collection, including itself, and/or facilities of the like.Most frequently, the user interface communicates with operating systems,other program components, and/or the like. The user interface maycontain, communicate, generate, obtain, and/or provide programcomponent, system, user, and/or data communications, requests, and/orresponses.

Web Browser

A Web browser component 9918 is a stored program component that isexecuted by a CPU. The Web browser may be a hypertext viewingapplication such as Apple's (mobile) Safari®, Google's Chrome®,Microsoft Internet Explorer®, Mozilla's Firefox®, Netscape Navigator®,and/or the like. Secure Web browsing may be supplied with 128 bit (orgreater) encryption by way of HTTPS, SSL, and/or the like. Web browsersallowing for the execution of program components through facilities suchas ActiveX, AJAX, (D)HTML, FLASH, Java, JavaScript, web browser plug-inAPIs (e.g., FireFox®, Safari® Plug-in, and/or the like APIs), and/or thelike. Web browsers and like information access tools may be integratedinto PDAs, cellular telephones, and/or other mobile devices. A Webbrowser may communicate to and/or with other components in a componentcollection, including itself, and/or facilities of the like. Mostfrequently, the Web browser communicates with information servers,operating systems, integrated program components (e.g., plug-ins),and/or the like; e.g., it may contain, communicate, generate, obtain,and/or provide program component, system, user, and/or datacommunications, requests, and/or responses. Also, in place of a Webbrowser and information server, a combined application may be developedto perform similar operations of both. The combined application wouldsimilarly affect the obtaining and the provision of information tousers, user agents, and/or the like from the MLPO enabled nodes. Thecombined application may be nugatory on systems employing Web browsers.

Mail Server

A mail server component 9921 is a stored program component that isexecuted by a CPU 9903. The mail server may be an Internet mail serversuch as, but not limited to: dovecot, Courier IMAP, Cyrus IMAP, Maildir,Microsoft Exchange, sendmail, and/or the like. The mail server may allowfor the execution of program components through facilities such as ASP,ActiveX, (ANSI) (Objective-) C (++), C # and/or .NET, CGI scripts, Java,JavaScript, PERL, PHP, pipes, Python, WebObjects®, and/or the like. Themail server may support communications protocols such as, but notlimited to: Internet message access protocol (IMAP), MessagingApplication Programming Interface (MAPI)/Microsoft Exchange, post officeprotocol (POPS), simple mail transfer protocol (SMTP), and/or the like.The mail server can route, forward, and process incoming and outgoingmail messages that have been sent, relayed and/or otherwise traversingthrough and/or to the MLPO. Alternatively, the mail server component maybe distributed out to mail service providing entities such as Google's®cloud services (e.g., Gmail and notifications may alternatively beprovided via messenger services such as AOL's Instant Messenger®,Apple's iMessage®, Google Messenger®, SnapChat®, etc.).

Access to the MLPO mail may be achieved through a number of APIs offeredby the individual Web server components and/or the operating system.

Also, a mail server may contain, communicate, generate, obtain, and/orprovide program component, system, user, and/or data communications,requests, information, and/or responses.

Mail Client

A mail client component 9922 is a stored program component that isexecuted by a CPU 9903. The mail client may be a mail viewingapplication such as Apple Mail®, Microsoft Entourage®, MicrosoftOutlook®, Microsoft Outlook Express®, Mozilla®, Thunderbird®, and/or thelike. Mail clients may support a number of transfer protocols, such as:IMAP, Microsoft Exchange, POPS, SMTP, and/or the like. A mail client maycommunicate to and/or with other components in a component collection,including itself, and/or facilities of the like. Most frequently, themail client communicates with mail servers, operating systems, othermail clients, and/or the like; e.g., it may contain, communicate,generate, obtain, and/or provide program component, system, user, and/ordata communications, requests, information, and/or responses. Generally,the mail client provides a facility to compose and transmit electronicmail messages.

Cryptographic Server

A cryptographic server component 9920 is a stored program component thatis executed by a CPU 9903, cryptographic processor 9926, cryptographicprocessor interface 9927, cryptographic processor device 9928, and/orthe like. Cryptographic processor interfaces will allow for expeditionof encryption and/or decryption requests by the cryptographic component;however, the cryptographic component, alternatively, may run on a CPU.The cryptographic component allows for the encryption and/or decryptionof provided data. The cryptographic component allows for both symmetricand asymmetric (e.g., Pretty Good Protection (PGP)) encryption and/ordecryption. The cryptographic component may employ cryptographictechniques such as, but not limited to: digital certificates (e.g.,X.509 authentication framework), digital signatures, dual signatures,enveloping, password access protection, public key management, and/orthe like. The cryptographic component will facilitate numerous(encryption and/or decryption) security protocols such as, but notlimited to: checksum, Data Encryption Standard (DES), Elliptical CurveEncryption (ECC), International Data Encryption Algorithm (IDEA),Message Digest 5 (MD5, which is a one way hash operation), passwords,Rivest Cipher (RC5), Rijndael, RSA (which is an Internet encryption andauthentication system that uses an algorithm developed in 1977 by RonRivest, Adi Shamir, and Leonard Adleman), Secure Hash Algorithm (SHA),Secure Socket Layer (SSL), Secure Hypertext Transfer Protocol (HTTPS),Transport Layer Security (TLS), and/or the like. Employing suchencryption security protocols, the MLPO may encrypt all incoming and/oroutgoing communications and may serve as node within a virtual privatenetwork (VPN) with a wider communications network. The cryptographiccomponent facilitates the process of “security authorization” wherebyaccess to a resource is inhibited by a security protocol wherein thecryptographic component effects authorized access to the securedresource. In addition, the cryptographic component may provide uniqueidentifiers of content, e.g., employing and MD5 hash to obtain a uniquesignature for a digital audio file. A cryptographic component maycommunicate to and/or with other components in a component collection,including itself, and/or facilities of the like. The cryptographiccomponent supports encryption schemes allowing for the securetransmission of information across a communications network to allow theMLPO component to engage in secure transactions if so desired. Thecryptographic component facilitates the secure accessing of resources onthe MLPO and facilitates the access of secured resources on remotesystems; i.e., it may act as a client and/or server of securedresources. Most frequently, the cryptographic component communicateswith information servers, operating systems, other program components,and/or the like. The cryptographic component may contain, communicate,generate, obtain, and/or provide program component, system, user, and/ordata communications, requests, and/or responses.

The MLPO Database

The MLPO database component 9919 may be embodied in a database and itsstored data. The database is a stored program component, which isexecuted by the CPU; the stored program component portion configuringthe CPU to process the stored data. The database may be a faulttolerant, relational, scalable, secure database such as MySQL®, Oracle®,Sybase®, etc. may be used. Additionally, optimized fast memory anddistributed databases such as IBM's Netezza®, MongoDB's MongoDB®,opensource Hadoop®, opensource VoltDB, SAP's Hana®, etc. Relationaldatabases are an extension of a flat file. Relational databases consistof a series of related tables. The tables are interconnected via a keyfield. Use of the key field allows the combination of the tables byindexing against the key field; i.e., the key fields act as dimensionalpivot points for combining information from various tables.Relationships generally identify links maintained between tables bymatching primary keys. Primary keys represent fields that uniquelyidentify the rows of a table in a relational database. Alternative keyfields may be used from any of the fields having unique value sets, andin some alternatives, even non-unique values in combinations with otherfields. More precisely, they uniquely identify rows of a table on the“one” side of a one-to-many relationship.

Alternatively, the MLPO database may be implemented using various otherdata-structures, such as an array, hash, (linked) list, struct,structured text file (e.g., XML), table, and/or the like. Suchdata-structures may be stored in memory and/or in (structured) files. Inanother alternative, an object-oriented database may be used, such asFrontier™, ObjectStore, Poet, Zope, and/or the like. Object databasescan include a number of object collections that are grouped and/orlinked together by common attributes; they may be related to otherobject collections by some common attributes. Object-oriented databasesperform similarly to relational databases with the exception thatobjects are not just pieces of data but may have other types ofcapabilities encapsulated within a given object. If the MLPO database isimplemented as a data-structure, the use of the MLPO database 9919 maybe integrated into another component such as the MLPO component 9935.Also, the database may be implemented as a mix of data structures,objects, and relational structures. Databases may be consolidated and/ordistributed in countless variations (e.g., see Distributed MLPO below).Portions of databases, e.g., tables, may be exported and/or imported andthus decentralized and/or integrated.

In one embodiment, the database component 9919 includes several tables9919 a-z: An accounts table 9919 a includes fields such as, but notlimited to: an accountID, accountOwnerID, accountContactID, assetIDs,deviceIDs, paymentIDs, transactionIDs, userIDs, accountType (e.g.,agent, entity (e.g., corporate, non-profit, partnership, etc.),individual, etc.), accountCreationDate, accountUpdateDate, accountName,accountNumber, routingNumber, linkWalletsID,accountPrioritAccaountRatio, accountAddress, accountState,accountZlPcode, accountCountry, accountEmail, accountPhone,accountAuthKey, accountIPaddress, accountURLAccessCode, accountPortNo,accountAuthorizationCode, accountAcces sPrivileges, accountPreferences,accountRestrictions, and/or the like;

A users table 9919 b includes fields such as, but not limited to: auserID, userSSN, taxID, userContactID, accountID, assetIDs, deviceIDs,paymentIDs, transactionIDs, userType (e.g., agent, entity (e.g.,corporate, non-profit, partnership, etc.), individual, etc.),namePrefix, firstName, middleName, lastName, nameSuffix, DateOfBirth,userAge, userName, userEmail, userSocialAccountID, contactType,contactRelationship, userPhone, userAddress, userCity, userState,userZIPCode, userCountry, userAuthorizationCode, userAccessPrivilges,userPreferences, userRestrictions, and/or the like (the user table maysupport and/or track multiple entity accounts on a MLPO);

An devices table 9919 c includes fields such as, but not limited to:deviceID, sensorIDs, accountID, assetIDs, paymentIDs, deviceType,deviceName, deviceManufacturer, deviceModel, deviceVersion,deviceSerialNo, deviceIPaddress, deviceMACaddress, device_ECID,deviceUUID, deviceLocation, deviceCertificate, deviceOS, appIDs,deviceResources, deviceVersion, authKey, deviceSecureKey,walletAppInstalledFlag, deviceAccessPrivileges, devicePreferences,deviceRestrictions, hardware_config, software_config, storage_location,sensor_value, pin_reading, data_length, channel_requirement,sensor_name, sensor_model_no, sensor_manufacturer, sensor_type,sensor_serial_number, sensor_power_requirement,device_power_requirement, location, sensor_associated_tool,sensor_dimensions, device_dimensions, sensor_communications_type,device_communications_type, power_percentage, power_condition,temperature_setting, speed_adjust, hold_duration, part_actuation, and/orthe like. Device table may, in some embodiments, include fieldscorresponding to one or more Bluetooth profiles, such as those publishedat https://www.bluetooth.org/en-us/specification/adopted-specifications,and/or other device specifications, and/or the like;

An apps table 9919 d includes fields such as, but not limited to: appID,appName, appType, appDependencies, accountID, deviceIDs, transactionID,userID, appStoreAuthKey, appStoreAccountID, appStoreIPaddress,appStoreURLaccessCode, appStorePortNo, appAccessPrivileges,appPreferences, app Restrictions, portNum, access_API_call,linked_wallets_list, and/or the like;

An assets table 9919 e includes fields such as, but not limited to:assetID, accountID, userID, distributorAccountID, distributorPaymentID,distributorOnwerID, as setOwnerID, as setType, as setSourceDeviceID, assetSourceDeviceType, as setSourceDeviceName,assetSourceDistributionChannelID, assetSourceDistributionChannelType,assetSourceDistributionChannelName, assetTargetChannelID,assetTargetChannelType, assetTargetChannelName, assetName,assetSeriesName, assetSeriesSeason, assetSeriesEpisode, assetCode,assetQuantity, assetCost, assetPrice, assetValue, assetManufactuer,assetModelNo, assetSerialNo, assetLocation, assetAddress, assetState,assetZIPcode, assetState, assetCountry, assetEmail, assetIPaddress,assetURLaccessCode, assetOwnerAccountID, subscriptionIDs,assetAuthroizationCode, assetAccessPrivileges, assetPreferences,assetRestrictions, assetAPI, assetAPIconnectionAddress, and/or the like;

A payments table 9919 f includes fields such as, but not limited to:paymentID, accountID, userID, couponID, couponValue, couponConditions,couponExpiration, paymentType, paymentAccountNo, paymentAccountName,paymentAccountAuthorizationCodes, paymentExpirationDate, paymentCCV,paymentRoutingNo, paymentRoutingType, paymentAddress, paymentState,paymentZIPcode, paymentCountry, paymentEmail, paymentAuthKey,paymentIPaddress, paymentURLaccessCode, paymentPortNo,paymentAccessPrivileges, paymentPreferences, payementRestrictions,and/or the like;

An transactions table 9919 g includes fields such as, but not limitedto: transactionID, accountID, assetIDs, deviceIDs, paymentIDs,transactionIDs, userID, merchantID, transactionType, transactionDate,transactionTime, transactionAmount, transactionQuantity,transactionDetails, productsList, productType, productTitle,productsSummary, productParamsList, transactionNo,transactionAccessPrivileges, transactionPreferences,transactionRestrictions, merchantAuthKey, merchantAuthCode, and/or thelike;

An merchants table 9919 h includes fields such as, but not limited to:merchantID, merchantTaxID, merchanteName, merchantContactUserID,accountID, issuerID, acquirerID, merchantEmail, merchantAddress,merchantState, merchantZIPcode, merchantCountry, merchantAuthKey,merchantIPaddress, portNum, merchantURLaccessCode, merchantPortNo,merchantAccessPrivileges, merchantPreferences, merchantRestrictions,and/or the like;

An ads table 9919 i includes fields such as, but not limited to: adID,advertiserID, adMerchantID, adNetworkID, adName, adTags, advertiserName,adSponsor, adTime, adGeo, adAttributes, adFormat, adProduct, adText,adMedia, adMedialD, adChannelID, adTagTime, adAudioSignature, adHash,adTemplateID, adTemplateData, adSourceID, adSourceName,adSourceServerIP, adSourceURL, adSourceSecurityProtocol, adSourceFTP,adAuthKey, adAccessPrivileges, adPreferences, adRestrictions,adNetworkXchangeID, adNetworkXchangeName, adNetworkXchangeCost,adNetworkXchangeMetricType (e.g., CPA, CPC, CPM, CTR, etc.),adNetworkXchangeMetricValue, adNetworkXchangeServer,adNetworkXchangePortNumber, publisherID, publisherAddress, publisherURL,publisherTag, publisherIndustry, publisherName, publisherDescription,siteDomain, siteURL, siteContent, siteTag, siteContext, siteImpression,siteVisits, siteHeadline, sitePage, siteAdPrice, sitePlacement,sitePosition, bidID, bidExchange, bidOS, bidTarget, bidTimestamp,bidPrice, bidImpressionID, bidType, bidScore, adType (e.g., mobile,desktop, wearable, largescreen, interstitial, etc.), assetID,merchantID, deviceID, userID, accountID, impressionID, impressionOS,impressionTimeStamp, impressionGeo, impressionAction, impressionType,impressionPublisherID, impressionPublisherURL, and/or the like;

A ScenarioResults table 9919 j includes fields such as, but not limitedto: simulationID, scenarioID, scenarioTimeframe, scenarioMarketFactorID,scenarioDistributionConfiguration,scenarioTrainedMachineLearningConfigurationData,scenarioSimulatedMarketFactorChange, scenarioAssociatedBusinessCycle,simulationMarketFactorRangeMin, simulationMarketFactorRangeMax,simulationMarketFactorRangeAverage, and/or the like;

A DTEs table 9919 k includes fields such as, but not limited to: DTE_ID,DTE_Type, DTE_LinkedSecurityID, DTE_TrainedConfigurationData,DTE_LinkedsimulationID, and/or the like;

An ExpectedReturns table 9919 l includes fields such as, but not limitedto: securityID, linkedSimulationID, linkedScenarioID,linkedScenarioSecurityExpectedReturn, and/or the like;

A PredefinedScenarios table 9919 m includes fields such as, but notlimited to: predefinedScenarioID, customizedMarketFactorID,customizedMarketFactorRangeMin, customizedMarketFactorRangeMax,customizedMarketFactorRangeAverage,predefinedScenarioAssociatedSimulationID,predefinedScenarioAssociatedFilteredMarketScenarios, and/or the like;

An asset_sim_wide table 9919 n includes fields such as, but not limitedto: asset_id, pricing_dt, sim_id, returns, and/or the like;

An asset_measure table 9919 o includes fields such as, but not limitedto: asset_id, pricing_dt, sim_id, market_id, measure_name,measure_value, and/or the like;

A market_data table 9919 z includes fields such as, but not limited to:market_data_feed_ID, asset_ID, asset_symbol, asset_name, spot_price,bid_price, ask_price, and/or the like; in one embodiment, the marketdata table is populated through a market data feed (e.g., Bloomberg'sPhatPipe®, Consolidated Quote System® (CQS), Consolidated TapeAssociation® (CTA), Consolidated Tape System® (CTS), Dun & Bradstreet®,OTC Montage Data Feed® (OMDF), Reuter's Tib®, Triarch®, US equity tradeand quote market Data®, Unlisted Trading Privileges® (UTP) Trade DataFeed® (UTDF), UTP Quotation Data Feed® (UQDF), and/or the like feeds,e.g., via ITC 2.1 and/or respective feed protocols), for example,through Microsoft's® Active Template Library and Dealing ObjectTechnology's real-time toolkit Rtt.Multi.

In one embodiment, the MLPO database may interact with other databasesystems. For example, employing a distributed database system, queriesand data access by search MLPO component may treat the combination ofthe MLPO database, an integrated data security layer database as asingle database entity (e.g., see Distributed MLPO below).

In one embodiment, user programs may contain various user interfaceprimitives, which may serve to update the MLPO. Also, various accountsmay require custom database tables depending upon the environments andthe types of clients the MLPO may need to serve. It should be noted thatany unique fields may be designated as a key field throughout. In analternative embodiment, these tables have been decentralized into theirown databases and their respective database controllers (i.e.,individual database controllers for each of the above tables). Employingvarious data processing techniques, one may further distribute thedatabases over several computer systemizations and/or storage devices.Similarly, configurations of the decentralized database controllers maybe varied by consolidating and/or distributing the various databasecomponents 9919 a-z. The MLPO may be configured to keep track of varioussettings, inputs, and parameters via database controllers.

The MLPO database may communicate to and/or with other components in acomponent collection, including itself, and/or facilities of the like.Most frequently, the MLPO database communicates with the MLPO component,other program components, and/or the like. The database may contain,retain, and provide information regarding other nodes and data.

The MLPOs

The MLPO component 9935 is a stored program component that is executedby a CPU. In one embodiment, the MLPO component incorporates any and/orall combinations of the aspects of the MLPO that was discussed in theprevious figures. As such, the MLPO affects accessing, obtaining and theprovision of information, services, transactions, and/or the like acrossvarious communications networks. The features and embodiments of theMLPO discussed herein increase network efficiency by reducing datatransfer requirements the use of more efficient data structures andmechanisms for their transfer and storage. As a consequence, more datamay be transferred in less time, and latencies with regard totransactions, are also reduced. In many cases, such reduction instorage, transfer time, bandwidth requirements, latencies, etc., willreduce the capacity and structural infrastructure requirements tosupport the MLPO's features and facilities, and in many cases reduce thecosts, energy consumption/requirements, and extend the life of MLPO'sunderlying infrastructure; this has the added benefit of making the MLPOmore reliable. Similarly, many of the features and mechanisms aredesigned to be easier for users to use and access, thereby broadeningthe audience that may enjoy/employ and exploit the feature sets of theMLPO; such ease of use also helps to increase the reliability of theMLPO. In addition, the feature sets include heightened security as notedvia the Cryptographic components 9920, 9926, 9928 and throughout, makingaccess to the features and data more reliable and secure

The MLPO transforms machine learning simulation request, decision treeensembles training request, expected returns calculation request,portfolio construction request, predefined scenario constructionrequest, portfolio returns visualization request inputs, via MLPOcomponents (e.g., MLSSP, DTET, ERC, PC, PSC, SPRV, BPRV, PRV, ARMC),into machine learning simulation response, decision tree ensemblestraining response, expected returns calculation response, portfolioconstruction response, predefined scenario construction response,portfolio returns visualization response outputs.

The MLPO component enabling access of information between nodes may bedeveloped by employing various development tools and languages such as,but not limited to: Apache® components, Assembly, ActiveX, binaryexecutables, (ANSI) (Objective-) C (++), C # and/or .NET, databaseadapters, CGI scripts, Java, JavaScript, mapping tools, procedural andobject oriented development tools, PERL, PHP, Python, shell scripts, SQLcommands, web application server extensions, web developmentenvironments and libraries (e.g., Microsoft's® ActiveX; Adobe® AIR, FLEX& FLASH; AJAX; (D)HTML; Dojo, Java; JavaScript; jQuery(UI); MooTools;Prototype; script.aculo.us; Simple Object Access Protocol (SOAP);SWFObject; Yahoo!® User Interface; and/or the like), WebObjects®, and/orthe like. In one embodiment, the MLPO server employs a cryptographicserver to encrypt and decrypt communications. The MLPO component maycommunicate to and/or with other components in a component collection,including itself, and/or facilities of the like. Most frequently, theMLPO component communicates with the MLPO database, operating systems,other program components, and/or the like. The MLPO may contain,communicate, generate, obtain, and/or provide program component, system,user, and/or data communications, requests, and/or responses.

Distributed MLPOs

The structure and/or operation of any of the MLPO node controllercomponents may be combined, consolidated, and/or distributed in anynumber of ways to facilitate development and/or deployment. Similarly,the component collection may be combined in any number of ways tofacilitate deployment and/or development. To accomplish this, one mayintegrate the components into a common code base or in a facility thatcan dynamically load the components on demand in an integrated fashion.As such a combination of hardware may be distributed within a location,within a region and/or globally where logical access to a controller maybe abstracted as a singular node, yet where a multitude of private,semiprivate and publicly accessible node controllers (e.g., viadispersed data centers) are coordinated to serve requests (e.g.,providing private cloud, semi-private cloud, and public cloud computingresources) and allowing for the serving of such requests in discreteregions (e.g., isolated, local, regional, national, global cloudaccess).

The component collection may be consolidated and/or distributed incountless variations through various data processing and/or developmenttechniques. Multiple instances of any one of the program components inthe program component collection may be instantiated on a single node,and/or across numerous nodes to improve performance throughload-balancing and/or data-processing techniques. Furthermore, singleinstances may also be distributed across multiple controllers and/orstorage devices; e.g., databases. All program component instances andcontrollers working in concert may do so through various data processingcommunication techniques.

The configuration of the MLPO controller will depend on the context ofsystem deployment. Factors such as, but not limited to, the budget,capacity, location, and/or use of the underlying hardware resources mayaffect deployment requirements and configuration. Regardless of if theconfiguration results in more consolidated and/or integrated programcomponents, results in a more distributed series of program components,and/or results in some combination between a consolidated anddistributed configuration, data may be communicated, obtained, and/orprovided. Instances of components consolidated into a common code basefrom the program component collection may communicate, obtain, and/orprovide data. This may be accomplished through intra-application dataprocessing communication techniques such as, but not limited to: datareferencing (e.g., pointers), internal messaging, object instancevariable communication, shared memory space, variable passing, and/orthe like. For example, cloud services such as Amazon Data Services®,Microsoft Azure®, Hewlett Packard Helion®, IBM® Cloud services allow forMLPO controller and/or MLPO component collections to be hosted in fullor partially for varying degrees of scale.

If component collection components are discrete, separate, and/orexternal to one another, then communicating, obtaining, and/or providingdata with and/or to other component components may be accomplishedthrough inter-application data processing communication techniques suchas, but not limited to: Application Program Interfaces (API) informationpassage; (distributed) Component Object Model ((D)COM), (Distributed)Object Linking and Embedding ((D)OLE), and/or the like), Common ObjectRequest Broker Architecture (CORBA), Jini local and remote applicationprogram interfaces, JavaScript Object Notation (JSON), Remote MethodInvocation (RMI), SOAP, process pipes, shared files, and/or the like.Messages sent between discrete component components forinter-application communication or within memory spaces of a singularcomponent for intra-application communication may be facilitated throughthe creation and parsing of a grammar A grammar may be developed byusing development tools such as lex, yacc, XML, and/or the like, whichallow for grammar generation and parsing capabilities, which in turn mayform the basis of communication messages within and between components.

For example, a grammar may be arranged to recognize the tokens of anHTTP post command, e.g.:

-   -   w3c-post http:// . . . Value1

where Value1 is discerned as being a parameter because “http://” is partof the grammar syntax, and what follows is considered part of the postvalue. Similarly, with such a grammar, a variable “Value1” may beinserted into an “http://” post command and then sent. The grammarsyntax itself may be presented as structured data that is interpretedand/or otherwise used to generate the parsing mechanism (e.g., a syntaxdescription text file as processed by lex, yacc, etc.). Also, once theparsing mechanism is generated and/or instantiated, it itself mayprocess and/or parse structured data such as, but not limited to:character (e.g., tab) delineated text, HTML, structured text streams,XML, and/or the like structured data. In another embodiment,inter-application data processing protocols themselves may haveintegrated parsers (e.g., JSON, SOAP, and/or like parsers) that may beemployed to parse (e.g., communications) data. Further, the parsinggrammar may be used beyond message parsing, but may also be used toparse: databases, data collections, data stores, structured data, and/orthe like. Again, the desired configuration will depend upon the context,environment, and requirements of system deployment.

For example, in some implementations, the MLPO controller may beexecuting a PHP script implementing a Secure Sockets Layer (“SSL”)socket server via the information server, which listens to incomingcommunications on a server port to which a client may send data, e.g.,data encoded in JSON format. Upon identifying an incoming communication,the PHP script may read the incoming message from the client device,parse the received JSON-encoded text data to extract information fromthe JSON-encoded text data into PHP script variables, and store the data(e.g., client identifying information, etc.) and/or extractedinformation in a relational database accessible using the StructuredQuery Language (“SQL”). An exemplary listing, written substantially inthe form of PHP/SQL commands, to accept JSON-encoded input data from aclient device via an SSL connection, parse the data to extractvariables, and store the data to a database, is provided below:

<?PHP header(′Content-Type: text/plain′); // set ip address and port tolisten to for incoming data $address = ‘192.168.0.100’ ; $port = 255; //create a server-side SSL socket, listen for/accept incomingcommunication $sock = socket_create(AF_INET, SOCK_STREAM, 0);socket_bind($sock, $address, $port) or die(‘Could not bind to address’);socket_listen($sock); $client = socket_accept($sock); // read input datafrom client device in 1024 byte blocks until end of message do {  $input= “”;  $input = socket_read($client, 1024);  $data .= $input; }while($input != “”); // parse data to extract variables $obj =json_decode($data, true); // store input data in a databasemysql_connect(″201.408.185.132″,$DBserver, $password); // accessdatabase server mysql_select(″CLIENT_DB.SQL″); // select database toappend mysql_query(“INSERT INTO UserTable (transmission) VALUES($data)”); // add data to UserTable table in a CLIENT databasemysql_close(″CLIENT_DB.SQL″); // close connection to database ?>

Also, the following resources may be used to provide example embodimentsregarding SOAP parser implementation:

  http://www.xav.com/perl/site/lib/SOAP/Parser.htmlhttp://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm.IBMDI.d oc/referenceguide295.htmand other parser implementations:

  http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm.IBMDI.d oc/referenceguide259.htmall of which are hereby expressly incorporated by reference.

In order to address various issues and advance the art, the entirety ofthis application for Machine Learning Portfolio Simulating andOptimizing Apparatuses, Methods and Systems (including the Cover Page,Title, Headings, Field, Background, Summary, Brief Description of theDrawings, Detailed Description, Claims, Abstract, Figures, Appendices,and otherwise) shows, by way of illustration, various embodiments inwhich the claimed innovations may be practiced. The advantages andfeatures of the application are of a representative sample ofembodiments only, and are not exhaustive and/or exclusive. They arepresented only to assist in understanding and teach the claimedprinciples. It should be understood that they are not representative ofall claimed innovations. As such, certain aspects of the disclosure havenot been discussed herein. That alternate embodiments may not have beenpresented for a specific portion of the innovations or that furtherundescribed alternate embodiments may be available for a portion is notto be considered a disclaimer of those alternate embodiments. It will beappreciated that many of those undescribed embodiments incorporate thesame principles of the innovations and others are equivalent. Thus, itis to be understood that other embodiments may be utilized andfunctional, logical, operational, organizational, structural and/ortopological modifications may be made without departing from the scopeand/or spirit of the disclosure. As such, all examples and/orembodiments are deemed to be non-limiting throughout this disclosure.Further and to the extent any financial and/or investment examples areincluded, such examples are for illustrative purpose(s) only, and arenot, nor should they be interpreted, as investment advice. Also, noinference should be drawn regarding those embodiments discussed hereinrelative to those not discussed herein other than it is as such forpurposes of reducing space and repetition. For instance, it is to beunderstood that the logical and/or topological structure of anycombination of any program components (a component collection), othercomponents, data flow order, logic flow order, and/or any presentfeature sets as described in the figures and/or throughout are notlimited to a fixed operating order and/or arrangement, but rather, anydisclosed order is exemplary and all equivalents, regardless of order,are contemplated by the disclosure. Similarly, descriptions ofembodiments disclosed throughout this disclosure, any reference todirection or orientation is merely intended for convenience ofdescription and is not intended in any way to limit the scope ofdescribed embodiments. Relative terms such as “lower”, “upper”,“horizontal”, “vertical”, “above”, “below”, “up”, “down”, “top” and“bottom” as well as derivative thereof (e.g., “horizontally”,“downwardly”, “upwardly”, etc.) should not be construed to limitembodiments, and instead, again, are offered for convenience ofdescription of orientation. These relative descriptors are forconvenience of description only and do not require that any embodimentsbe constructed or operated in a particular orientation unless explicitlyindicated as such. Terms such as “attached”, “affixed”, “connected”,“coupled”, “interconnected”, and similar may refer to a relationshipwherein structures are secured or attached to one another eitherdirectly or indirectly through intervening structures, as well as bothmovable or rigid attachments or relationships, unless expresslydescribed otherwise. Furthermore, it is to be understood that suchfeatures are not limited to serial execution, but rather, any number ofthreads, processes, services, servers, and/or the like that may executeasynchronously, concurrently, in parallel, simultaneously,synchronously, and/or the like are contemplated by the disclosure. Assuch, some of these features may be mutually contradictory, in that theycannot be simultaneously present in a single embodiment. Similarly, somefeatures are applicable to one aspect of the innovations, andinapplicable to others. In addition, the disclosure includes otherinnovations not presently claimed. Applicant reserves all rights inthose presently unclaimed innovations including the right to claim suchinnovations, file additional applications, continuations, continuationsin part, divisions, and/or the like thereof. As such, it should beunderstood that advantages, embodiments, examples, functional, features,logical, operational, organizational, structural, topological, and/orother aspects of the disclosure are not to be considered limitations onthe disclosure as defined by the claims or limitations on equivalents tothe claims. It is to be understood that, depending on the particularneeds and/or characteristics of a MLPO individual and/or enterpriseuser, database configuration and/or relational model, data type, datatransmission and/or network framework, syntax structure, and/or thelike, various embodiments of the MLPO, may be implemented that allow agreat deal of flexibility and customization. For example, aspects of theMLPO may be adapted for derivatives. While various embodiments anddiscussions of the MLPO have included machine learning and databasesystems, however, it is to be understood that the embodiments describedherein may be readily configured and/or customized for a wide variety ofother applications and/or implementations.

What is claimed is:
 1. A machine learning predefined scenarioconstructing apparatus, comprising: a memory; a component collection inthe memory; a processor disposed in communication with the memory andconfigured to issue a plurality of processor-executable instructionsfrom the component collection, the processor-executable instructionsstructured as: obtain, via at least one processor, a user selection of aset of simulated market scenarios via a simulation selectioninteraction-interface mechanism, the set of simulated market scenariosgenerated using a set of deep learning neural networks, each simulatedmarket scenario in the set of simulated market scenarios structured tocomprise a set of simulated market factor values corresponding to a setof market factors; determine, via at least one processor, a range ofunfiltered simulated market factor values for each market factor fromthe set of market factors, the range of unfiltered simulated marketfactor values for a market factor structured to include a minimumsimulated market factor value and a maximum simulated market factorvalue in the set of simulated market scenarios for the respective marketfactor; generate, via at least one processor, a set of market factorinteraction-interface mechanisms, each market factorinteraction-interface mechanism in the set of market factorinteraction-interface mechanisms structured to be associated with amarket factor from the set of market factors and structured to displaythe range of unfiltered simulated market factor values for therespective market factor; obtain, via at least one processor, a usermodification to a range of allowable values of a market factor from theset of market factors via the market factor interaction-interfacemechanism associated with the modified market factor; update, via atleast one processor, a set of customized market factors from the set ofmarket factors based on the user modification; determine, via at leastone processor, a range of allowable values for each customized marketfactor from the set of customized market factors; filter, via at leastone processor, the set of simulated market scenarios based on thedetermined ranges of allowable values for the set of customized marketfactors to determine a set of filtered simulated market scenarios havingsimulated market factor values that fall within the range of allowablevalues for each customized market factors from the set of customizedmarket factors; determine, via at least one processor, a range offiltered simulated market factor values for each market factor from theset of market factors, the range of filtered simulated market factorvalues for a market factor structured to include a minimum simulatedmarket factor value and a maximum simulated market factor value in theset of filtered simulated market scenarios for the respective marketfactor; and generate, via at least one processor, an updated set ofmarket factor interaction-interface mechanisms, each updated marketfactor interaction-interface mechanism in the set of updated marketfactor interaction-interface mechanisms structured to be associated witha market factor from the set of market factors and structured to displaythe range of filtered simulated market factor values for the respectivemarket factor.
 2. The apparatus of claim 1, further, comprising: theinstructions to generate the set of simulated market scenarios using theset of deep learning neural networks are structured to compriseinstructions to: determine, via at least one processor, a set ofhistorical market scenarios and a set of time period buckets; determine,via at least one processor, for each time period bucket from the set oftime period buckets, a subset of historical market scenarios, from theset of historical market scenarios, associated with the respective timeperiod bucket; train, via at least one processor, for each time periodbucket from the set of time period buckets, a deep learning neuralnetwork, from the set of deep learning neural networks, using the subsetof historical market scenarios associated with the respective timeperiod bucket; determine, via at least one processor, for each timeperiod bucket from the set of time period buckets, a number of simulatedmarket scenarios to generate using the trained deep learning neuralnetwork associated with the respective time period bucket; and generate,via at least one processor, for each time period bucket from the set oftime period buckets, the determined number of simulated market scenariosfor the respective time period bucket, using the trained deep learningneural network associated with the respective time period bucket.
 3. Theapparatus of claim 2, further, comprising: the instructions to determinethe set of historical market scenarios are structured to compriseinstructions to: determine, via at least one processor, a historicaldata set, a rolling window period length, and the set of market factors;determine, via at least one processor, a set of rolling window periodsusing the historical data set and the rolling window period length; andcalculate, via at least one processor, for each market factor from theset of market factors, for each rolling window period from the set ofrolling window periods, a change to the respective market factor duringthe respective rolling window period, each historical market scenariofrom the set of historical market scenarios structured to comprisecalculated changes to the set of market factors during a rolling windowperiod.
 4. The apparatus of claim 3, further, comprising: theinstructions to calculate a change to a market factor during a rollingwindow period are structured to comprise instructions to: determine, viaat least one processor, the delta between values of the market factor ata beginning time point and an ending time point of the rolling windowperiod.
 5. The apparatus of claim 4, further, comprising: theprocessor-executable instructions structured as: determine, via at leastone processor, that historical data for the market factor during therolling window period is unavailable for a time point; and impute, viaat least one processor, the unavailable historical data for the timepoint using a machine learning method.
 6. The apparatus of claim 3,further, comprising: the rolling window period length is structured tobe equal to the time period length.
 7. The apparatus of claim 2,further, comprising: the set of time period buckets is structured tohave an equal fixed length for each time period bucket.
 8. The apparatusof claim 2, further, comprising: the set of time period buckets isstructured to have a variable length for each time period bucket, thevariable length for each time period bucket determined by judging theoverall goodness of fit between the set of simulated market scenariosand the set of historical market scenarios.
 9. The apparatus of claim 2,further, comprising: the instructions to train a deep learning neuralnetwork for a time period bucket using the associated subset ofhistorical market scenarios are structured to comprise instructions to:select, via at least one processor, a historical market scenario fromthe associated subset of historical market scenarios; and train, via atleast one processor, the deep learning neural network for the timeperiod bucket on the selected historical market scenario using avariational autoencoder.
 10. The apparatus of claim 9, further,comprising: the deep learning neural network for the time period bucketis trained to generate a set of Gaussian mixture latent variables. 11.The apparatus of claim 10, further, comprising: the instructions togenerate simulated market scenarios for the time period bucket, usingthe trained deep learning neural network associated with the time periodbucket, are structured to comprise instructions to: generate, via atleast one processor, a set of random values for the set of Gaussianmixture latent variables; and generate a simulated market scenario, fromthe simulated market scenarios for the time period bucket, from thegenerated set of random values using a neural network decoder of thetrained deep learning neural network associated with the time periodbucket.
 12. The apparatus of claim 1, further, comprising: thesimulation selection interaction-interface mechanism is structured tocomprise a pricing date selection interaction-interface mechanism and asimulation model selection interaction-interface mechanism.
 13. Theapparatus of claim 1, further, comprising: the range of unfilteredsimulated market factor values for a market factor structured to includean average simulated market factor value in the set of simulated marketscenarios for the market factor; and the range of filtered simulatedmarket factor values for the market factor structured to include anaverage value in the set of filtered simulated market scenarios for themarket factor.
 14. The apparatus of claim 1, further, comprising: eachmarket factor interaction-interface mechanism in the set of marketfactor interaction-interface mechanisms is structured to include aslider interaction-interface mechanism to affect user modification to arange of allowable values of a market factor associated with therespective market factor interaction-interface mechanism.
 15. Theapparatus of claim 1, further, comprising: the instructions to updatethe set of customized market factors based on the user modification arestructured to comprise instructions to add the modified market factor tothe set of customized market factors.
 16. The apparatus of claim 1,further, comprising: the instructions to update the set of customizedmarket factors based on the user modification are structured to compriseinstructions to remove the modified market factor from the set ofcustomized market factors.
 17. The apparatus of claim 1, further,comprising: the processor-executable instructions structured as:generate, via at least one processor, a predefined scenariodatastructure that includes a simulation identifier associated with theset of simulated market scenarios, identifiers of customized marketfactors from the set of customized market factors, and the ranges ofallowable values for the set of customized market factors.
 18. Theapparatus of claim 1, further, comprising: the processor-executableinstructions structured as: generate, via at least one processor, apredefined scenario datastructure that includes a simulation identifierassociated with the set of simulated market scenarios, and identifiersof filtered simulated market scenarios from the set of filteredsimulated market scenarios.
 19. The apparatus of claim 1, further,comprising: the processor-executable instructions structured as:generate, via at least one processor, a set of factor group filterinteraction-interface mechanisms, each factor group filterinteraction-interface mechanism in the set of factor group filterinteraction-interface mechanisms structured to be associated with asubset of market factor interaction-interface mechanisms from the set ofmarket factor interaction-interface mechanisms.
 20. The apparatus ofclaim 19, further, comprising: the processor-executable instructionsstructured as: obtain, via at least one processor, a user selection of afactor group filter interaction-interface mechanism in the set of factorgroup filter interaction-interface mechanisms; and generate, via atleast one processor, a filtered set of market factorinteraction-interface mechanisms, each filtered market factorinteraction-interface mechanism in the set of filtered market factorinteraction-interface mechanisms structured to be associated with theselected factor group filter interaction-interface mechanism.
 21. Theapparatus of claim 1, further, comprising: the set of simulated marketscenarios is further generated using a set of multi-variate mixturedatastructures.
 22. The apparatus of claim 1, further, comprising: theprocessor-executable instructions structured as: calculate, via at leastone processor, a set of expected returns for a set of securities, eachexpected return in the set of expected returns configured as calculatedfor a security during a simulated market scenario in the set ofsimulated market scenarios using: the respective security's conditionalBeta during the respective simulated market scenario, determined using aset of decision tree ensembles, trained to estimate conditional Beta ofthe respective security, based on a first subset of the set of simulatedmarket factor values, and the respective security's conditional defaultprobability during the respective simulated market scenario, determinedusing a set of decision tree ensembles, trained to estimate conditionaldefault probability of the respective security, based on a second subsetof the set of simulated market factor values.
 23. A machine learningpredefined scenario constructing processor-readable, non-transientmedium, comprising processor-executable instructions structured as:obtain, via at least one processor, a user selection of a set ofsimulated market scenarios via a simulation selectioninteraction-interface mechanism, the set of simulated market scenariosgenerated using a set of deep learning neural networks, each simulatedmarket scenario in the set of simulated market scenarios structured tocomprise a set of simulated market factor values corresponding to a setof market factors; determine, via at least one processor, a range ofunfiltered simulated market factor values for each market factor fromthe set of market factors, the range of unfiltered simulated marketfactor values for a market factor structured to include a minimumsimulated market factor value and a maximum simulated market factorvalue in the set of simulated market scenarios for the respective marketfactor; generate, via at least one processor, a set of market factorinteraction-interface mechanisms, each market factorinteraction-interface mechanism in the set of market factorinteraction-interface mechanisms structured to be associated with amarket factor from the set of market factors and structured to displaythe range of unfiltered simulated market factor values for therespective market factor; obtain, via at least one processor, a usermodification to a range of allowable values of a market factor from theset of market factors via the market factor interaction-interfacemechanism associated with the modified market factor; update, via atleast one processor, a set of customized market factors from the set ofmarket factors based on the user modification; determine, via at leastone processor, a range of allowable values for each customized marketfactor from the set of customized market factors; filter, via at leastone processor, the set of simulated market scenarios based on thedetermined ranges of allowable values for the set of customized marketfactors to determine a set of filtered simulated market scenarios havingsimulated market factor values that fall within the range of allowablevalues for each customized market factors from the set of customizedmarket factors; determine, via at least one processor, a range offiltered simulated market factor values for each market factor from theset of market factors, the range of filtered simulated market factorvalues for a market factor structured to include a minimum simulatedmarket factor value and a maximum simulated market factor value in theset of filtered simulated market scenarios for the respective marketfactor; and generate, via at least one processor, an updated set ofmarket factor interaction-interface mechanisms, each updated marketfactor interaction-interface mechanism in the set of updated marketfactor interaction-interface mechanisms structured to be associated witha market factor from the set of market factors and structured to displaythe range of filtered simulated market factor values for the respectivemarket factor.
 24. A machine learning predefined scenario constructingprocessor-implemented system, comprising: means to processprocessor-executable instructions; means to issue processor-issuableinstructions from a processor-executable component collection via themeans to process processor-executable instructions, theprocessor-issuable instructions structured as: obtain, via at least oneprocessor, a user selection of a set of simulated market scenarios via asimulation selection interaction-interface mechanism, the set ofsimulated market scenarios generated using a set of deep learning neuralnetworks, each simulated market scenario in the set of simulated marketscenarios structured to comprise a set of simulated market factor valuescorresponding to a set of market factors; determine, via at least oneprocessor, a range of unfiltered simulated market factor values for eachmarket factor from the set of market factors, the range of unfilteredsimulated market factor values for a market factor structured to includea minimum simulated market factor value and a maximum simulated marketfactor value in the set of simulated market scenarios for the respectivemarket factor; generate, via at least one processor, a set of marketfactor interaction-interface mechanisms, each market factorinteraction-interface mechanism in the set of market factorinteraction-interface mechanisms structured to be associated with amarket factor from the set of market factors and structured to displaythe range of unfiltered simulated market factor values for therespective market factor; obtain, via at least one processor, a usermodification to a range of allowable values of a market factor from theset of market factors via the market factor interaction-interfacemechanism associated with the modified market factor; update, via atleast one processor, a set of customized market factors from the set ofmarket factors based on the user modification; determine, via at leastone processor, a range of allowable values for each customized marketfactor from the set of customized market factors; filter, via at leastone processor, the set of simulated market scenarios based on thedetermined ranges of allowable values for the set of customized marketfactors to determine a set of filtered simulated market scenarios havingsimulated market factor values that fall within the range of allowablevalues for each customized market factors from the set of customizedmarket factors; determine, via at least one processor, a range offiltered simulated market factor values for each market factor from theset of market factors, the range of filtered simulated market factorvalues for a market factor structured to include a minimum simulatedmarket factor value and a maximum simulated market factor value in theset of filtered simulated market scenarios for the respective marketfactor; and generate, via at least one processor, an updated set ofmarket factor interaction-interface mechanisms, each updated marketfactor interaction-interface mechanism in the set of updated marketfactor interaction-interface mechanisms structured to be associated witha market factor from the set of market factors and structured to displaythe range of filtered simulated market factor values for the respectivemarket factor.
 25. A machine learning predefined scenario constructingprocessor-implemented process, comprising executing processor-executableinstructions to: obtain, via at least one processor, a user selection ofa set of simulated market scenarios via a simulation selectioninteraction-interface mechanism, the set of simulated market scenariosgenerated using a set of deep learning neural networks, each simulatedmarket scenario in the set of simulated market scenarios structured tocomprise a set of simulated market factor values corresponding to a setof market factors; determine, via at least one processor, a range ofunfiltered simulated market factor values for each market factor fromthe set of market factors, the range of unfiltered simulated marketfactor values for a market factor structured to include a minimumsimulated market factor value and a maximum simulated market factorvalue in the set of simulated market scenarios for the respective marketfactor; generate, via at least one processor, a set of market factorinteraction-interface mechanisms, each market factorinteraction-interface mechanism in the set of market factorinteraction-interface mechanisms structured to be associated with amarket factor from the set of market factors and structured to displaythe range of unfiltered simulated market factor values for therespective market factor; obtain, via at least one processor, a usermodification to a range of allowable values of a market factor from theset of market factors via the market factor interaction-interfacemechanism associated with the modified market factor; update, via atleast one processor, a set of customized market factors from the set ofmarket factors based on the user modification; determine, via at leastone processor, a range of allowable values for each customized marketfactor from the set of customized market factors; filter, via at leastone processor, the set of simulated market scenarios based on thedetermined ranges of allowable values for the set of customized marketfactors to determine a set of filtered simulated market scenarios havingsimulated market factor values that fall within the range of allowablevalues for each customized market factors from the set of customizedmarket factors; determine, via at least one processor, a range offiltered simulated market factor values for each market factor from theset of market factors, the range of filtered simulated market factorvalues for a market factor structured to include a minimum simulatedmarket factor value and a maximum simulated market factor value in theset of filtered simulated market scenarios for the respective marketfactor; and generate, via at least one processor, an updated set ofmarket factor interaction-interface mechanisms, each updated marketfactor interaction-interface mechanism in the set of updated marketfactor interaction-interface mechanisms structured to be associated witha market factor from the set of market factors and structured to displaythe range of filtered simulated market factor values for the respectivemarket factor.